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^>This  report  describes  an  Information  collection  and  correlation  (ICC)  decision 
support  system  designed  to  aid  the  process  of  combat  information  production  In 
Marine  amphibious  operations.  Three  operators  perform  Information  correlation: 
one  at  the  reconnaissance  and  surveillance  (R&S)  station  of  the  division 
Intelligence  Center,  another  at  wing  level  and  a  third  one  atJMAf^level.  They 
correlate  new  Information  with  existing  Information  In  order  to  maintain  a  flic 
which  contains  the  most  current  picture  of  the  enen\y  situation  In  the  form  of 
round  tracks.  In  addltlon.tthe  MAF  operator  performs  combat  Information  - 
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>coordi nation.  The  present  unaided  information  correlation  system  is  likely  to 
create  information  overload  resulting  In  processing  delays  and  failure  to  make 
combat  Information  available  in  a  timely  manner.  The  ICC  support  system  was 
designed  to  reduce  this  overload  by  automating  or  aiding  of  some  of  the  functions 
involved  in  combat  information  production.  The  system  covers  the  following 
processes:  (1)  reliability  assessment,  (2)  identity  identification,  (3) 
conflict  identification,  (4)  conflict  resolution,  and  (5)  Information  selection. 
The  support  system  has  been  designed  for  implementation  In  the  Marine  Tactical 
Combat  Operations  (TCO)  System. 
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Information  acquisition  a*tl  transfer  as  the 
need  for :  Improvement. '  Due  M  the  stringent 
the  need  for  timely  and  accuratelnfoii^ 
making  Is  Increased.  At  the  seam  time  the  ampoet  of- 
from  various  sources  (sensors*  automated  syi 
literally  burying  commanders  In  afYood  gf  t 
Intelligence  analysts  provide  a|gregatefi||«l 
of  estimates.  Although  usefUl  for  cOMRaatiersout  in 
aggregated  Information  does  not  fulfill  tftetr 
on  enemy  units,  positions  and  movements.  inorder  to  fu 
ment  for  providing  this  type  of  Ififormatlon  to  Marine 
the  Narine  Corps  Tactical  Support  Systems  Activity 
system  concept  aimed  at  producing  combat  ini 
bat  Information  Is  Included  In  the  f ramework  of  the 
tlons  (TOO)  system  as  that  information  about 
personnel  and  equipment  on  the  ground  made  aoailableinm 
after  ecme  technical  processing. 


The  main  problem  In  producing  combat  Information  fs  tbit 
due  to  the  existence  of  a  multitude  of  seniors  I(di1c3h:'||g 
provide  Information  about  the  same  enemy  position.  As  4 
Preliminary  System.  Description  Document  (PSDD)  Inf 
Is  an  operator  function.  Three  operatoftperform 
one  at  the  reconnaissance  end  surveillance  (R4S}$ 
Intelligence  Center,  another  at  wlng  lavel  and  a  t 
They  correlate  new  Information  wftn  exlstlnglofen 
a  TOO  file  which  contains  the  most  currant  plctire 
In  the  form  of  gfound  tracks.  In  addltlon  to  eomn 
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par  fori  cwwt  tufBfiit wO  coMlnH.  ♦  *a. .  tsiii’i 
responsibilities  and  resolves  possible  conflicts  between 
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Kftng  operators  with  regard  to  proposed  updates  of  the 


Operators  are  aided  In  their  tenet ions-by  sime  TC8  capabUltletef  *|p:f^ 
supportive  nature  such  a*  a  display  with  «*P  background,  -alertf 
computational  procedures.  Due  to  the  high  ntMber  of  expected  tensor 
sightings  and  the  large  ntmfeer  of  required  interactions  betweeneperatte# 
at  different  levels,  the  Infonaatlon  correlation  systee  defined  In  the 
PSOD  Is  likely  to  create  an  enonus  Intermatlotf  overToad  whlcb  wOuld 
result  In  long  processing  delays  and  failure  to  make  combat  information 
available  in  a  timely  inner.  . 


In  order  to  speed  up  the  process  of  combat  Information  productlon  and 
decrease  communication  requirements  between  various  levels,  an  InfOttmtlon 
collection  and  correlation  (ICC)  decision  support  system  was  conceited 
and  a  specific  design  was  selected  for  Implementation.  First  the  procefs 
of  Information  correlation  was  decomposed  Into  subprocesses.  Then  modules 
were  designed  which  automate  or  aid  the  defined  subprocesses.  F^ly-h 
framework  was  provided  around  which  the  modules  were  organized.  From  tee 
standpoint  of  operator  performance  In  correlating  Information  there  Is 
only  one  correlation  process.  From  am  organizational  standpoint,  however, 
two  correlation  processes  were  distinguished.  Jhese  are  (1)  local  eorrila*- 
tlon,  performed  on  sensor  reports  by  division,  wing  and  MAF  operators 
separately  and  resulting  In  proposed  track  file  modifications  and  (f) 
global  correlation  performed  by  a  MAF  operator  on  the  proposed  track  file  'd 
modifications  and  resulting  in  Implementation  or  deletion  of  these  pro* 
posed  modifications.  This  distinction  has  the  advantage  of  sepatetteip 
various  operators  functions  and  thus  reducing  communication*  requirements,  i 
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cesses:  (1)  reliability  assessment,  (2)  Identity . 
conflict  Identification,  (4)  conflict  resolution  and  <SJ:  * 

selection.  Reliability  assessment  Is  necessary  to  attach  alvatue  ffmerlC 
to  the  Incoming  information.  This  step  Is  partf^liriy  important  when  o 
paring  two  conflicting  pieces  of  infoismtlbn.  Identity  mdidl^ssbsHPtfie'#  IdMnil^Nf 
cations  are  fundamental  In  determining  whether  two  1  information  elinents  j 

refer  to  the  same  entity.  Proper  techniques  ha ve  been. prodded  to  aid  ' 

these  two  processes  by  handling  of  the  uncertainty  which  Is  attagbed  to  , 
Information  sources.  Finally  when  conflicts  are  Identified,  attenpts  *||v 
made  to  resolve  them.  If  a  conflict  cannot  be  resol  veduslng ;ts|ii|r:-a«r»1 
able  Information,  e.g. ,  by  disregarding  the  less  reliable  Information* 
more  information  must  be  sought  thus  requiring  selection:* of  the  most 
Informative  source  of  Information  as  the  collection  means.  %  -  ,v 


Automating  •'.nd  aiding  these  processes  are  expected  to  help  operators  to 
overcome  the  overload  problem  by  decreasing  the  average  processing  time* 
per  sighting.  Also,  by  providing  &  structure  which  limits  the  need  for 
various  level  operator  Interactions,  It  is  expected  to  decrease  even 
further  the  processing  time. 


A  specific  design  for  Implementation  of  the  ICC  concept  was  also  provided 
It  shows  the  feasibility  of  the  concept  from  an  Implementation  standpoint 
since  the  selected  design  does  not  require  extra  Information  nor  dees  it 
require  operators  to  perform  functions  net  already  required  without 
the  support  systom.  The  systomdrp^OOentimpr^ 
ques.  Although  representation  of  semjr%f  these  techniques  requires  com-  . 
plicated  mathematitol  notations,  fiirther  oiileMty 

to  the  Information  corr»1d^k^ of i'tttit.  mithamoiUa 
techniques  Is  solely  to  provide'1 

aiding'  to  the  functions  which  arm,.rpgjtf^  , 

with  or  without  a  decision  support  system. 


“V*!*  --’Vs  <  *  ; 


1.  INTRODUCTION 


1.1  Overview 


The  present  report  documents  the  results  of  the  second-year  effort  of  the 
decision  support  program.  During  the  first  program  year  a  methodology  for 
decision-aid  selection  was  established  based  on  a  taxonomy  of  the  Narine 
Amphibious  Brigade  (MAB)  decisions.  During  the  second  program  year,  this 
methodology  was  used  to  select  a  decision  aid  for  the  MAB  decision-making 
environment.  The  selected  decision  aid  is  in  fact  composed  of  a  family  of 
decision  aids  conceptually  organized  in  an  Information  Collection  and 
Correlation  (ICC)  decision  support  system  for  production  of  combat  infor¬ 
mation.  Within  the  framework  of  this  second  year  effort  a  specific  design 
was  also  provided.  Although  designed  for  an  amphibious  operation  of  Marine 
Amphibious  Force  (MAF)  size,  the  decision  support  system  is  transferable  to 
MAB  level  with  only  minor  modifications. 

1.2  Scope  of  the  Effort 

The  second-year  effort  is  planned  within  the  framework  of  a  program 
directed  toward  production  of  a  working  taxonomy  of  tactical  decisions  for 
the  Command,  Control  and  Communications  (C  )  environment  of  Marine  Corps 
coimanders.  The  program  focusses  on  the  Marine  Amphibious  Brigade  (MAB) 
decision  environment,  and  will  provide  a  base-line  for  a  systematic 
approach  to  design  and/or  selection  of  effective  decision  aids  for  the 
tactical  C  environment.  The  specific  objectives  of  the  program  are  as 
follows: 

(1)  Analyze  the  MAB  command  and  control  environment  in  terms  of 
its  tactical  commanders'  decisions,  information  needs  and 
operational  objectives. 


(2)  Oevelop  a  taxonomy  of  decision  tasks  encountered  in  the  MAB 
decision-making  environment,  and  identify  classes  of  decision 
tasks  requiring  similar  decision-making  skills  and  cognitive 
behaviors. 

(3)  Develop  a  taxonomy  of  potential  decision  makers  among  MAB 
commanders  at  different  levels  and  develop  a  taxonomy  of 
available,  as  well  as  plausible,  decision  aids. 

(4)  Identify  the  range  of  decision  aids  suitable  for  the  MAB 
environment. 

(5)  Recommend,  using  the  taxonomy,  high-payoff  decision  aids  and 
select  among  them  a  decision  aid  well  accepted  by  the  users. 

(6)  Design  a  software  system  for  the  simulation  and  demonstra¬ 
tion  of  the  selected  decision  aid. 

(7)  Implement  the  decision  aid  in-house  and  demonstrate  its 
operation. 

(8)  Transfer  the  decision  aid  to  the  MTACCS  Test  Facility  (MTF) 
and  investigate  the  suitability  of  possible  model  generaliza¬ 
tions. 

(9)  Design  a  test  plan  to  evaluate  the  effectiveness  of  the 
decision  aid. 

During  the  first  year  of  the  program  a  methodology  for  decision-aid  selec¬ 
tion  was  established  fulfilling  objectives  (1)  to  (4).  During  the  second 
year  of  the  program,  objectives  (5)  and  (6)  were  addressed. 

1.3  Method  of  Approach 

Of  particular  salience  in  this  program  is  that  Its  time  span  coincides 
with  Tactical  Combat  Operations  (TCO)  concept  validation  testing.  TOO 
is  envisioned  as  an  Information  system  In  which  microcomputers  control 
interactive  display  devices,  manage  a  distributed  data  base,  perform  com¬ 
putational  tasks  and  generate  hard  copy  records.  TCO,  which  consists  of 
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92  capabilities  supporting  the  functions  of  planning,  operations  and 
intelligence,  is  currently  undergoing  thorough  concept  validation  testing 
at  the  Marine  Corps  Tactical  System  Support  Activity  (MCTSSA),  Camp 
Pendleton,  on  the  Interim  Test  Facility  (ITF)  and  is  scheduled  for  extensive 
testing  on  the  Marine  Corps  Tactical  Command  and  Control  Systems  (MTACCS) 
Test  Facility  (MTF).  Treating  the  individual  decision  aids  which  make  up 
the  decision  support  system  as  TCO  capabilities  provides  an  excellent 
opportunity  for  "benchmark"  evaluation  of  these  decision  aids  in  an  opera¬ 
tional  context. 

In  order  to  accommodate  the  specific  requirement  of  the  decision-aid 
inclusion  into  the  TCO  system,  the  decision-aid  selection  methodology 
developed  during  the  first  year  was  refined.  (Details  are  presented  in 
Appendices  A,  B  and  C.)  The  refined  methodology  facilitates  decision-aid 
selection  when  inclusion  of  the  aid  into  a  system  is  desired  by  providing 
an  overall  degree  of  merit  for  the  decision  aid  with  regard  to  all  the 
decision  tasks  already  supported  by  the  system.  For  instance  Bayesian 
classification  techniques  were  found  to  have  a  high  degree  of  suitability 
for  inclusion  into  TCO.  Although  Bayesian  classification  techniques  were 
Included  into  the  ICC,  i.e.,  developed  as  an  aid  for  information  correla¬ 
tion  and  collection,  they  could  be  developed  for  other  decision  areas  as 
well.  This  point  is  Illustrated  in  Appendix  F  which  describes  a  decision 
aid  concept  utilizing  Bayesian  classification  for  situation  assessment. 

Due  to  the  specific  needs  of  Marine  Corps  coirananders  for  timely  and 
accurate  information,  the  decision  area  "information  correlation"  takes  on 
special  importance.  At  the  present  stage  of  TCO  concept  development,  this 
function  is  an  operator  function.  The  operators  who  perform  correlation 
functions  are  subject  to  extreme  task  overload.  The  decision  support 
system  described  In  this  report  is  expected  to  reduce  this  overload  sub¬ 
stantially  while  increasing  the  accuracy  of  the  processes  Involved. 


1-3 


a-.-. > mpr* -*  <  ~r  K 


The  correlation  process  was  analyzed  In  terms  of  the  decision  subprocesses 
It  Involves.  Modules  were  then  conceived  to  support  these  subprocesses  by 
providing  either  automation  or  aiding.  A  framework  was  also  provided 
around  which  the  modules  were  organized.  The  framework  and  Its  various 
modules  constitute  the  ICC  decision  support  system.  The  system  was 
specified  and  an  Implementation  design  was  provided.  Requirement  analysis 
results  have  shown  that  this  design  Is  feasible  and  can  be  Implemented  In 
the  TCO  simulated  environment. 

1.4  Program  Continuation 

During  the  third  program  year,  the  ICC  decision  support  system  will  be 
transferred  and  implemented  into  the  MTF.  Also,  an  evaluation  plan,  in 
the  lines  of  TCO  concept  validation  testing,  will  be  designed. 

1.5  Organization  of  the  Report 

The  report  is  organized  in  four  chapters  and  six  appendices.  Chapter  2 
introduces  the  problem  of  combat  information  correlation.  Chapter  3 
describes  the  system  concept  while  Chapter  4  describes  the  design  selected 
for  implementation.  Chapter  5  concludes  the  report.  Appendices  A,  B  and 
C  altogether  document  the  required  refinement  to  the  decision-aid  selection 
methodology.  Appendices  D  and  E  respectively  describe  the  computation  of 
the  surface  of  the  a-level  confidence  ellipse  for  a  2 -dimensional  normal 
variable  and  a  queueing  model  for  ICC  system  behavior  analysis.  Finally, 
Appendix  F  describes  a  decision  aid  concept  for  situation  assessment  which 
also  utilizes  one  of  the  techniques  Included  in  the  ICC  support  system. 
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2.  PROBLEM  ANALYSIS 


2.1  Introduction 


Amphibious  operations  in  the  1980's  will  be  characterized  by  a  combination 
of  sophisticated  weaponry,  a  high  concentration  of  fire  power,  high  speed 
of  maneuver  enhanced  by  the  use  of  armored/motorized/mechanized  forces, 
and  enemy's  capabilities  to  disrupt  and  deceive  friendly  forces. 

"The  term  'fog  of  battle  '  aptly  describes  the  situation  which 
will  face  the  ground  combat  cormxnder  in  this  environment . 

Enemy  electronic  warfare  and  a  rapidly  changing  situation  will 
combine  to  give  him  scanty  or  erroneous  information  in  seme 
areas.  In  other  areas  the  sophisticated  conmcnications  and 
data  collection  capabilities  available  to  him  will  tend  to 
bury  him  in  a  flood  of  electronically  generated  raw  data. 

If  he  is  to  prevail,  he  must  be  able  to  rapidly  adjust  his 
plans  and  execute  changes  to  his  scheme  of  maneuver  to  react 
to  changes  in  the  battlefield  situation. "  (TCO  Maneuver 
Control  Paper.) 

The  combination  of  time  pressure  and  information  overload  cannot  be 
effectively  coped  with  using  the  present  tactical  command  and  control 
system.  This  system  works  and  has  worked  effectively  for  many  years,  but 
it  is  too  slow  to  accommodate  the  requirements  of  the  post  1980  battle¬ 
field.  This  operational  deficiency  was  identified  in  the  Required 
Operational  Capability  (ROC)  document  which  states: 


Technological  progress  has  resulted  in  vastly  improved  sensor, 
cormunications ,  and  automated  processing  capabilities.  Auto¬ 
mation  is  being  introduced  into  virtually  every  functional 
area  of  command  and  control:  fire  support,  air  control , 
intelligence,  logistics  and  manpower.  After  1986,  the  unpre¬ 
cedented  volume  of  information  from  these  systems  that  is 
pertinent  to  tactical  decisions  cannot  be  received  and 
processed  at  operation  centers  without  the  aid  of  automation. 
Current  manual  methods  of  message  processing ,  data  filing , 
retrieval,  and  posting  to  plotting  boards  are  slew  and 
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susceptible  to  inaccuracies  and  mission  of  relevant  infor¬ 
mation  and  are,  therefore ,  inadequate  to  support  the  timeliness 
and  accuracy  requirements  of  Marine  Corps  comnanders  in  the 
post  1980’s 

As  a  result,  the  Marine  Corps  defined  the  requirement  for  a  Tactical 
Combat  Operations  (TCO)  System  to  overcome  the  identified  operational 
deficiency  of  the  present  system.  The  ROC  document  briefly  summarizes 
TCO  as  "An  on-line,  interactive,  secure  tactical  command  and  control 
system  designed  to  enhance  the  capability  of  the  commander  and  his 
operational  staff  to  conduct  combat  operations  and  planning." 

A  detailed  description  of  TCO  is  included  In  the  TCO  Preliminary  System 
Description  Document  (PSDD).  Basically,  the  system  consists  of  92 
capabilities  which  support  a  number  of  military  functions.  Again  quoting 
the  ROC:  "As  a  minimum,  TCO  would  provide  additional  support  of  the 
following  functions: 

(a)  Planning,  coordinating  and  supervising  the  tactical 
employment  of  units. 

(b)  Controlling  the  current  ground  combat  situation. 

(c)  Evaluating  the  tactical  situation  and  preparing 
operations  estimates. 

(d)  Integrating  fire  with  maneuver. 

(e)  Receiving,  transmitting,  and  displaying  data/information. 

(f)  Determining  priorities  for  allocations  of  personnel, 
weapons,  equipment  and  ammunition. 

(g)  Preparing  and  distributing  operations  plans  and  orders. 

(h)  Developing,  preparing,  and  supervising  the  execution  of 
training  programs  and  field  exercises. 

(1)  Preparing  and  submitting  reports." 


TCO  Is  envisioned  as  an  Information  system  in  which  microcomputers 
control  interactive  display  devices,  manage  a  distributed  data  base, 
perform  computational  tasks  and  generate  hard  copy  records  in  order  to 
provide  automated  assistance  to  the  tactical  commander  and  his  staff 
in  the  areas  of  planning.  Intelligence  and  operations. 

TCO  is  the  focal  point  of  the  Marine  Tactical  Command  and  Control  Systems 
(MTACCS)  family,  a  conceptual  association  of  eight  command  and  control 
systems,  interacting,  functionally  oriented  and  using  the  same  design 
philosophy.  The  MTACCS  Test  Facility  (MTF)  at  the  Marine  Corps  Tactical 
Systems  Support  Activity  1MCTSSA)  (Camp  Pendleton)  provides  a  test  bed 
for  these  systems  by  allowing  simulation  of  real-life  combat  situations. 
System  capabilities  are  simulated  and  their  relative  contribution  to 
performance  enhancement  can  be  assessed  (Kemple,  Stephens  and  Crolotte, 
1980). 

Similarly,  decision  aids  can  be  designed  and  implemented  as  system 
capabilities.  The  MTF  offers  an  excellent  opportunity  for  benchmark 
testing  of  decision  aids.  Once  the  effectiveness  of  the  decision  aids 
has  been  evaluated,  a  good  basis  exists  for  decision  with  regard  to  their 
actual  inclusion  into  the  system. 

2.2  Aiding  Requirement  for  TCO 

In  order  to  allow  selection  of  a  decision  aid  for  Inclusion  in  the 
TCO  system,  the  decision  aid  selection  methodology  needed  to  be  refined. 
The  results  of  this  methodology  refinement  are  presented  In  Appendix  A. 

As  a  preliminary  step  In  defining  this  refined  methodology,  an  assessment 
of  the  relative  Importance  of  TCO-supported  decision  task  areas  for 
mission  effectiveness  was  carried  out.  This  assessment  was  performed 
through  a  structured  interview  of  Marine  Corps  personnel  using  a  decom¬ 
position  of  TCO-supported  Marine  Corps  functions.  The  most  striking 
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result  In  this  assessment  Is  the  overwhelming  Importance  of  operations 
(67%)  and  Intelligence  (25%)  over  planning  (8%  only).  Rated  very  high 
in  operations  was  ground  maneuver  control  (23%). 

The  particular  emphasis  of  ground  maneuver  control  in  Amphibious  Operations 
is  well-known  and  had  been  previously  singled  out  by  MCTSSA  (TCO  Maneuver 
Control  Concept  Paper).  Ground  maneuver  takes  its  significance  for  units 
in  contact  with  the  enemy,  i.e.,  at  battalion  level.  "The  Narine  infantry 
battalion  ia  the  basic  tactical  unit  of  the  ground  combat  power  in  the 
Marine  Corps.  It  provides  the  nucleus  of  the  battalion  landing  team  for 
amphibious  and  Marine  amphibious  unit  air-ground  task  force  operations. " 
(FMFM  6-3.)  For  these  units  mobility  is  the  crucial  issue  and  consequently 
any  change  in  equipment  apparatus,  etc.  should  enhance  their  mobility— 
not  hamper  them. 

As  stated  in  the  TCO  Maneuver  Control  Concept  Paper: 

Cormanders  influence  the  conduct  of  maneuver  by  modifying 
the  concept  of  operations,  reallocating  available  assets  or 
changing  the  missions  of  subordinate  units.  The  decision  to 
do  one  or  a  combination  of  these  things  is  based  on  the 
information  available  to  the  cormanders  the  quality  of  his 
decision  will  be  directly  related  to  the  quality  of  the 
information  available  at  the  time  it  must  be  made. 

Thus,  timely  and  accurate  information  must  be  available  to  commanders  in 
order  to  enhance  decision  making. 

Decision  making  at  battalion  level  is  characterized  by  (1)  time  pressure 
and  (2)  information  overload.  To  cope  with  these  problems  and  be  able  to 
accommodate  the  needs  of  commanders  out  in  the  field  for  timely  and 
accurate  information,  a  number  of  TCO  capabilities  were  designed.  These 
capabilities  are  geared  toward  presentation  of  near  real-time  graphic  and 
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textual  display  of  tactical  information  on  demand.  It  would  provide 
the  comander  with  the  capability  to  develop,  store,  edit  and  disseminate , 
over  standard  communication  links,  information  associated  with  the 
command,  control,  and  coordination  efforts.  (Infantry  Battalion  Concept 
Paper  for  TCO.) 

The  actual  production  of  real-time  information  gathered  from  various 
sources,  in  particular  sophisticated  sensors  and  automated  data  systems, 
poses  the  specific  problem  of  information  correlation.  Information 
correlation  was  also  identified  as  an  important  decision  task  area 
within  intelligence  (see  Appendix  A).  At  the  present  time,  i.e.,  as 
described  in  the  PSDD,  information  correlation  is  a  TCO  operator  function. 
Consequently,  aiding  would  be  particularly  suitable  in  this  important 
area  in  order  to  speed-up  the  production  of  usable  information  and  at  the 
same  time  ensure  accuracy. 

2.3  Combat  Information 


As  demonstrated  earlier,  commanders  in  the  field  require  timely  and  accurate 
information.  The  type  of  information  they  require,  however,  must  be  clearly 
defined.  From  raw  data  to  intelligence,  information  passes  through  various 
stages  of  processing.  Raw  data  would  certainty  be  timely,  but  it  would  be 
detrimental  if  non-accurate.  In  addition,  raw  data  would  probably  be  too 
voluminous  to  be  meaningful.  Buried  in  overwhelming  amounts  of  raw  data, 
the  decision  maker  could  easily  overlook  the  important  facts. 

On  the  other  hand,  the  intelligence  process  is  often  very  long  so  that 
waiting  for  its  completion  to  transmit  information  to  commanders  would  not 
be  acceptable.  Consequently,  somewhere  between  raw  data  and  intelligence, 
an  amount  of  data  processing  exists  which  realizes  the  best  tradeoff 
between  timeliness  and  meaningful ness. 
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Raw  information  is  currently  available  to  commanders  through  the  use  of 
the  hot  line.  The  drawback  is  that  this  information  goes  directly  from 
the  source  (e.g.,  the  BASS  van)  to  the  user  and  Is  not  correlated  with 
information  coming  from  other  sources. 

Considerations  of  this  sort  led  MCTSSA  to  define  the  notion  of  combat 
information  (McDonough  and  Lawson,  1979)  as:  that  information  about  the 
location  of  enemy  weapons,  personnel  and  equipment  on  the  ground  which  is 
made  available  immediately ,  after  only  technical  processing.  It  differs 
from  intelligence  in  that  intelligence  is  the  result  of  the  analysis  of 
many  diverse  elements  of  information  and  provides  identification  of  enemy 
units  as  well  as  predictions  and  estimates  of  enemy  intentions  and 
capabilities.  Combat  information  is  the  ground  equivalent  of  the  track 
information  on  enemy  aircraft  provided  by  the  TAOC.  It  is  utilized  by 
intelligence  analysts  as  one  input  in  the  production  of  intelligence.  It 
is  also  used  simultaneously  by  aviation  and  fire  support  agencies  to  select 
targets  for  immediate  engagement  and  by  maneuver  control  agencies  to 
determine  the  objectives  of  maneuver  and  immediate  threats  to  friendly 
forces. 

Although  the  term  "combat  information"  is  for  many  people  a  synonym  of 
"unconfirmed  intelligence,"  we  have  retained  the  definition  of  McDonough 
and  Lawson  (1979).  This  definition  should,  however,  be  refined  since 
it  is  very  hard  to  determine  where  correlation  ends  and  analysis  begins. 

A  specific  definition  of  what  correlation  consists  of,  i.e.,  the  process 
it  involves,  therefore  naturally  yields  a  working  definition  of  combat 
Information.  To  Illustrate  the  difference  between  combat  Information  and 
intelligence,  consider  Figure  2-1  which  depicts  the  Interaction  between 
G2  and  commander  during  ground  maneuver  control.  Under  the  scrutiny  of 
a  number  of  sensors,  the  environment  provides  information  to  the  Recon¬ 
naissance  and  Surveillance  station  of  the  Intelligence  Center.  The  sensors 


FIGURE  2-1. 

G2/C0MMANDER  INTERACTION  DURING  GROUND 
MANEUVER  CONTROL 


portrayed  in  this  figure  are  a  helicopterborne  infrared  seeker,  a  ground 
surveillance  radar,  an  individual  served  weapon  sight,  a  hand-placed  and 
an  artillery  delivered  unattended  ground  sensor  of  the  REMBASS  generation 
and  Infantrymen  in  direct  contact  with  the  eneny.  The  Reconnaissance  and 
Surveillance  station  creates  ground  tracks  which  represent  the  current 
picture  of  the  battlefield  together  with  its  history.  These  tracks  are 
available  without  delay  to  the  commander  and  yet  the  information  has  been 
correlated. 


The  ground  tracks  are  also  available  to  the  intelligence  station  within 
the  Intelligence  Center.  Together  with  other  information,  these  tracks 
allow  the  intelligence  analyst  to  perform  required  analyses,  estimates 
and  inferences  which  are  also  very  useful  to  the  commander.  The 
following  example,  extracted  from  the  PSDD  illustrates  this  point: 


'The  Battalion  is  operating  at  the  Forward  Edge  of  the  Battle 
Area  (FEBA) .  The  Intelligence  Officer  receives  a  combat  report 
from  ' A '  Company,  who  sighted  an  enemy  tank  forward  of  their 
position.  The  Intelligence  Officer  fills  in  an  Enemy  Sighting 
Report.  Next ,  by  a  single  action ,  he  causes  the  report  to  be 
simultaneously  automatically  forwarded,  to  update  his  files,  and 
to  be  graphically  displayed  on  his  enemy  situation  display. 
Reviewing  the  situation  on  his  DSD,  the  Intelligence  Officer 
notes  an  enemy  track,  received  in  response  to  a  previous  SRI, 
within  1000  meters  of  the  sighting.  Re  "hooks"  the  symbol  and 
reviews  the  text  display  of  the  correlated  c&nbat  information. 

The  amplifying  information  indicates  that  five  tanks  suspected 
to  belong  to  the  2d  Bn  20Sth  were  sighted  moving  southwest  two 
hours  earlier.  Noting  the  Unit  ID,  the  Intelligence  Officer 
recalls  that  recent  intelligence  summaries  and  responses  to 
his  previously  submitted  Ad  Roc  queries  had  mentioned  the  205th. 
Querying  his  intelligence  files  about  the  2d  Bn  205th  the  Intelli¬ 
gence  Officer  is  provided  known  Unit  Order  of  Battle  information, 
which  includes  the  enemy  unit's  strength  and  weapons.  Equipped 
with  all  this  information  the  Intelligence  Officer  makes  his 
assessment.  Contacting  the  Commander  he  warns  that  Company  A ' s 
sighting  is  probably  one  of  five  tanks  previously  tracked  and 
that  four  others  are  no  doubt  in  the  imiediate  vicinity.  Re 
Passes  the  same  information  to  the  CO  of  Company  A,  and  he 
further  alerts  the  Battalion  and  Company  Commander  to  the 
combat  power  capabilities  of  the  2d  Bn  205th . " 


2.4  Present  Information  Correlation  Concept 

This  section  summarizes  the  present  concept  of  employment  of  TCO  to 
support  information  correlation  within  the  MAGTF  as  described  at  length 
by  McDonough  &  Lawson  (1979)  and  the  PSDD.  For  additional  details  the 
reader  should  refer  to  these  documents.  For  an  amphibious  operation  of 
MAF  size  there  are  three  intelligence  centers  each  managing  its  collection 
assets  as  depicted  in  Figure  2-2.  For  an  operation  of  MAB  size  only  one 
intelligence  center  exists  managing  all  collection  assets.  Although 
defined  at  MAF  level,  the  concept  is  immediately  transferable  to  the  MAB 
level.  Raw  data  coming  from  a  variety  of  sensors  is  received  by  division, 
wing,  and  MAF  intelligence  centers,  correlated  and  included  in  the  TCO 
data  base.  Combat  information  sources  are  portrayed  and  described  in 
Tables  2-1  and  2-2.  A  Combat  Information  Track  record  consists  of  the 
following  data  elements: 

(1)  Track  Identifier  number. 

(2)  Source(s)  of  the  information. 

(3)  Location  (UTM  coordinates); 

(4)  Time  of  detection. 

(5)  Classification. 

(a)  Troops. 

(b)  Vehicles. 

X  Tracked. 

2  Wheeled. 

(c)  Weapons  (type). 

(d)  Emitters  (Comm  or  Radar). 


(6)  Number  (of  troops,  vehicles  and/or  weapons). 

(7)  Activity. 


FIGURE  2-2. 

COMBAT  INFORMATION  FLOW 
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Multiple  Target  Electronic  Uerfere  System  (U.S.  Amy). 

QUICK  FIX 
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1  RPV 

1  l 
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Nuclear  Sunt  Detection  System  (U.S.  Army). 
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!  rtass 

I  l 

ftwote  Tactical  Airborne  SZ8INT  System  (USAF). 

COMPASS  EARS 

,  AN/ASQ-114(V)  , 

(USAf ) 

!  RIVET  JOINT 

I  1 

CLASSIFIED  (USAF) 

;  © 

i  Tha  following  allied  systems  typify  automated  sys cants  which  aight  provlda  combat  information 

t  to  tha  MA6TF. 

i  1 

< 

[  SATES 

f  * 

United  Kingdom.  Battlefield  Artillery  Target 

1  1 

Engagement  Systam. 

!  uavcll 

J  I 

Uni  tad  Kingdom.  Provides  G-2/G-3  support  slmillar 

to  TCO. 

8  EROS 

i  1 

German. 

GCAOGC 

1  1 
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1 
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Canadian. 

(a)  Moving  (direction/speed). 

(b)  Deployed. 

(c)  Assembling. 

(d)  Emitting. 

(e)  Firing. 

(8)  Unit  I.D. 

The  Combat  Information  available  is  summarized  in  the  track  record  file 
which  is  divided  into  two  segments  as  depicted  in  Figure  2-3:  (1)  the 

active  segment  which  contains  the  most  current  track  data  and  (2)  the 
history  segment  which  summarizes  past  track  behavior. 

When  a  sensor  report  is  received  at  the  center,  the  corresponding  infor¬ 
mation  is  correlated  with  existing  tracks  to  determine  if  it  corresponds 
to  (1)  a  new  track,  (2)  an  update  of  an  existing  track,  or  (3)  redundant 
or  less  reliable  data  about  an  existing  track.  This  correlation  is 
performed  by  an  operator  aided  by  displays  on  the  Dynamic  Situation  Display 
(DSD).  If  a  new  track  is  created  the  operator  assigns  to  it  an  identifier 
from  an  authorized  set  of  numbers  and  the  track  is  entered  in  the  track 
record  file  with  a  prefix  referring  to  the  track  manager  (e.g.,  D  for 
division).  A  center  which  creates  a  track  automatically  becomes  the  manager 
of  this  track.  Upon  updating  by  an  R  &  S  station  of  a  track  which  is  under 
management  of  another  R  &  S  station,  both  stations  must  agree  on  the  proposed 
update.  Conflicts  are  referred  to  the  track  coordinator  located  in  the 
MAF  intelligence  center.  In  the  present  concept  MAF  track  correlator  and 
track  coordinator  are  the  same  person.  In  addition  to  resolving  conflicts 
the  track  coordinator  may  reassign  track  management  responsibility  from 
one  center  to  another. 


2-14 


2.5  Areas  of  Improvement 

In  the  present  concept  of  employment  of  TCO  support  of  combat  information 
production  and  management,  the  operator  correlates  information  manually 
with  the  aid  of  certain  TCO  capabilities  of  a  general  supportive  nature 
only,  such  as  time  computations,  displays  of  ranges  and  line-of-sight 
calculations.  These  capabilities  probably  make  the  operator's  job  easier 
and  enhance  accuracy  and  timeliness.  They  do  not,  however,  provide  any 
direct  aid  to  the  decision  processes  which  are  involved  in  information 
correlation,  thus  do  not  significantly  reduce  processing  time.  At  the 
estimated  rate  of  600  sightings  per  hour  shared  between  division,  wing, 
and  MAF  operators,  i.e.,  on  the  average  one  sighting  every  20  seconds, 
it  is  very  likely  that  a  task  overload  would  occur.  In  the  decision 
support  system  concept  presented  in  Chapter  3,  the  information  correlation 
decision  process  is  decomposed  into  elementary  decision  sub-processes 
which  are  automated  or  aided.  It  is  expected  that,  by  employment  of  the 
support  system,  the  average  processing  time  per  sighting  will  be  much 
shorter  so  that  those  sightings  which  require  operator  intervention  can 
be  allocated  more  time. 

The  process  of  information  correlation  involves  comparing  pieces  of  infor¬ 
mation  to  decide  if  they  refer  to  (1)  the  same  entity  or  (2)  two  distinct 
entities.  When  referring  to  the  same  entity  the  pieces  of  information  can 
either  be  in  accord  or  create  a  conflict.  If  a  conflict  between  two 
pieces  of  information  occurs,  one  must  be  able  to  compare  these  Information 
in  terms  of  the  credibility  or  reliability  which  can  be  attached  to  them. 

Even  if  there  is  no  conflict,  it  is  essential  to  be  able  to  decide  If  a 
piece  of  information  is  unreliable  in  order  to  disregard  it.  If  a  conflict 
cannot  be  resolved  by  discarding  the  less  reliable  information,  more  Infor¬ 
mation  needs  to  be  collected.  A  decomposition  of  the  decision  functions 
Involved  in  the  process  of  Information  correlation  is  presented  In  Figure  2-4. 
In  the  following  chapter  the  proper  aiding  techniques  to  support  these 
functions  are  described. 
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FIGURE  2-4. 

DECISION  PROCESSES  INVOLVED  IN 
INFORMATION  CORRELATION 


An  improvement  in  overall  concept  framework  can  also  be  brought  about. 

Note  that  conflicts  in  proposed  track  file  modifications  could  occur  not 
only  between  division  and  wing,  but  also  between  division  and  MAF,  and 
wing  and  MAF.  The  last  two  types  of  conflict  differ  from  the  first  one 
only  in  the  sense  that  the  MAF  G2  can  resolve  conflicts  acting  as  the 
ultimate  decision  maker.  All  conflicts,  however,  involve  the  same 
processes  and  could  consequently  be  treated  alike.  Thus,  a  file  of  pro¬ 
posed  track  record  modifications  could  be  created  whose  elements  would  be 
subjected  to  analysis  to  identify  and  resolve  possible  conflicts.  This 
would  be,  of  course,  a  MAF  function.  The  creation  of  such  a  file  would, 
in  turn,  imply  centralization  of  track  management  functions  at  MAF  level. 
This  would  avoid  extra  communications  between  MAF,  Wing,  and  division  with 
regard  to  the  assignment  of  track  Identifiers.  This  modification  which 
is  of  an  organizational  nature  would  simplify  the  situation  and  decrease 
communication  requirements.  It  should  permit  an  improvement  in  decision 
quality  and  a  decrease  in  processing  time. 
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3.  DECISION  SUPPORT  SYSTEM  CONCEPT 


3.1  Overview 


The  decision  support  system  described  in  this  section  has  been  conceived 
to  provide  two  elements:  (1)  an  organizational  structure  and  (2)  a  set 
of  decision-aiding  modules  connected  to  each  other  within  the  defined 
structure.  The  decision-aiding  modules  support  the  decision-making 
functions  which  were  identified  previously  and  are  portrayed  in  Figure  2-4. 
From  an  organizational  viewpoint,  correlation  functions  fall  into  two 
categories: 

(1)  Local  correlation,  performed  on  sensor  reports  by  Division, 
Wing,  and  MAF  operators  separately,  and  resulting  in  proposed 
track  file  modifications. 

(2)  Global  correlation,  performed  by  an  MAF  operator  on  the 
proposed  track  file  modifications,  and  resulting  in  a 
decision  on  proposed  modifications  with  regard  to  their 
implementation. 

In  the  concept  depicted  in  Figure  3-1  local  and  global  correlations 
interact  as  follows:  Upon  receipt  of  a  sensor  report  the  local  correlation 
operator  (Div.,  Wing,  or  MAF)  correlates  this  new  sensor  information  with 
existing  information  contained  in  the  track  record  file.  When  the  local 
correlation  process  is  completed,  a  proposed  track  file  update  Is  issued 
and  sent  to  the  track  modifications  file.  The  specific  functions  and  mode 
of  operation  of  the  system  for  local  and  global  correlation  are  described 
in  Section  3.2. 

The  decision-aiding  modules  support  both  local  and  global  correlations 
which  actually  Involve  the  same  decision  processes.  Since  only  the 
implementation  of  these  techniques  Is  different,  from  local  correlation 
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FIGURE  3-1. 

DECISION  SUPPORT  SYSTEM  CONCEPT  OVERVIEW 
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to  global  correlation,  these  differences  will  appear  in  the  design  descrip¬ 
tion  only  (Chapter  4).  From  a  functional  standpoint,  the  aiding  techniques 
fall  into  two  categories:  (1)  information  correlation  and  (2)  information 
collection.  While  information  correlation  is  based  on  comparing  pieces  of 
information,  information  collection  consists  of  comparing  sources  of 
information.  The  various  techniques  which  can  be  used  to  aid  the  processes 
involved  in  information  correlation  and  collection,  together  with  their 
concept  of  employment,  are  described  in  Sections  3.3  and  3.4. 

3.2  Correlation  Concepts 

3.2.1  Local  Correlation.  As  depicted  in  Figure  3-2,  there  are  five 
decision-making  functions  involved  in  local  correlation:  (1)  reliability 
assessment,  (2)  conflict  identification,  (3)  conflict  resolution,  (4) 
information  selection,  and  (5)  track  record  file  modification  identifica¬ 
tion.  These  functions  are  articulated  as  follows:  upon  receipt  of  a  sensor 
report  its  reliability  score  is  computed;  simultaneously  possible  conflicts 
between  the  information  contained  in  the  sensor  report  and  the  track 
record  file  are  identified.  When  a  conflict  is  identified,  the  reliability 
scores  are  used  to  reject  tracks  with  very  low  reliability  and  possibly 
resolve  the  conflict.  When  it  is  not  possible  to  resolve  a  conflict  this 
way,  more  information  is  required.  Thus,  the  most  informative  way  to 
gather  information  is  determined.  The  gathering  of  this  information  yields 
a  sensor  report  which  is  again  input  to  the  system.  When  no  conflict  is 
identified  or  when  the  conflict  is  resolved,  the  proper  track  record  file 
modification  is  determined  and  sent  to  the  track  record  modification  file. 

3.2.2  Global  Correlation.  Global  correlation  consists  of  comparing  one 
element  of  the  track  record  modification  file  to  all  others  in  order  to 
determine  whether  to  Implement  this  proposed  modification.  The  global 
correlation  module  should,  therefore,  enable  comparison  between  any  two 
proposed  modifications  to  the  track  record  file. 
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FIGURE  3-2. 

LOCAL  CORRELATION  OVERVIEW 


The  functional  similarity  between  local  and  global  correlations  is  now 
apparent  since  they  both  involve  the  same  functions  except  reliability 
assessment  (see  Figure  3-3).  Since  a  modification  to  the  track  record 
file  is  proposed  on  the  basis  of  a  sensor  report,  the  reliability  score 
attached  to  this  sensor  report  will  be  carried  along  with  the  proposed 
modification. 

Two  proposed  modifications  to  the  track  record  file  are  compared  for  the 
purpose  of  identifying  a  possible  conflict.  When  a  conflict  is  indeed 
identified,  the  reliability  scores  are  used  to  disqualify  the  sufficiently 
low- reliability  modification,  if  such  a  case  exists.  In  the  case  where 
the  conflict  cannot  be  resolved  by  the  virtue  of  reliability  scores,  the 
most  effective  information  for  conflict  resolution  is  identified  and 
sought.  Upon  inspection  of  this  requested  information,  the  proper  modifi¬ 
cation  is  selected.  However,  if  a  moving  entity  is  involved  and  too  much 
time  has  already  elapsed,  the  operator  performs  the  conflict  resolution 
manually  (with  the  option  of  requesting  more  information  to  enable  him  to 
consider  the  displacement  of  the  entity).  At  the  end  of  the  execution  of 
this  module,  the  decision  is  made  as  to  whether  create  a  new  track  or 
update  an  existing  one. 

3.3  Information  Correlation  Aiding 

3.3.1  Reliability  Score.  In  order  to  assess  the  confidence  on  a  sensor 
report,  a  reliability  score  can  be  computed.  It  will  be  a  monotonic 
function  of  the  confidence  which  can  be  attached  to  a  sensor  report  in  each 
specific  situation.  Each  situation  can  be  defined  in  terms  of  two  para¬ 
meters:  (1)  the  characteristics  of  the  sensor  and  (2)  the  environmental 
conditions  under  which  the  sensor  operates.  Sensor  characteristics  dictate 
the  confidence  on  (1)  the  location  of  the  entity  reported  and  (2)  the 
accuracy  of  the  classification  provided. 
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FIGURE  3-3. 

GLOBAL  CORRELATION  OVERVIEW 


Generally,  the  uncertainty  about  a  location  can  be  summarized  by  a  disper¬ 
sion  matrix  e.  If  the  report  provides  2-dimensional  location  m,  it  is 
generally  assumed  that  the  actual  location  of  the  entity  is  m  +  x »  where 
x  is  distributed  as  N(0,  z)  .  Define  Ea  as  the  ellipse  such  that  there 
is  a  probability  a  that  the  actual  location  of  the  entity  is  in  Eq.  For 
a  given  value  of  o  (say  90%),  the  surface  Sy  of  this  ellipse  is  a  good 
indicator  of  the  sensor's  credibility  since  the  bigger  Sq,  the  less  precise 
the  sensor.  It  can  be  shown  (see  Appendix  D)  that  Sa  is  proportional  to  | e ( 
(the  determinant  of  e).  Consequently,  a  good  indicator  of  the  sensor's 
reliability  with  regard  to  its  localization  function  is  the  localization 
reliability  score  defined  as  oL  =  y[-«  For  a  very  unreliable  sensor, 

| £ |  is  large  and,  therefore,  is  close  to  zero,  while,  for  a  reliable 
sensor,  |e|  is  small  and  thus,  oL  is  close  to  1. 

The  accuracy  of  the  classification  provided  can  be  measured  by  the  mis- 
classification  rate  or  probability  of  error  Pg.  Thus,  the  classification 
reliability  score  can  be  defined  by  =  1  -  P  .  In  addition,  the  perfor¬ 
mance  of  certain  sensors  can  be  hampered  by  the  environmental  conditions 
which  are  related  to  the  terrain  (such  as  foliage,  which  restricts  line- 
of-sight)  or  enemy  activity  (such  as  jamming).  These  conditions  reduce 
the  above  scores  by  factors  p^  and  p^,  respectively.  The  general  relia¬ 
bility  score  is  a  combination  of  these  individual  scores:  r  =  w^p^  + 
wcpc°C’  w^ere  wl  +  Wq  *  1  and  w^  and  w^  are  weights  specified  in  advance 
and  Independent  from  the  particular  sensor  (e.g.,  w^  *  j  *  Wq).  The 
reliability  score  thus  defined  permits  discrimination  among  pieces  of 
information.  Its  computation  is  automatic  requiring  certain  human 
judgments  to  be  stored  ahead  of  time.  Other  required  human  judgments  are 
Incorporated  on-line  and  are  available  immediately  to  the  system. 


x  Is  distributed  normally  around  the  origin  with  dispersion  matrix  e, 
T.e. ,  its  p.d.f.  is  given  by  a  1  _  x'e^x 
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3.3.2  Identity  Testing.  When  comparing  the  information  contained  in 
two  sensor  reports  regarding  locations  very  close  to  each  other,  it  is 
legitimate  to  ask  whether  the  two  sensors  might  sense  the  same  entity. 

An  apparently  similar  problem  is  encountered  in  the  naval  environment 
where  several  ships  can  sense  the  same  entity  but  each  gets  "shifted" 
pictures  due  to  the  uncertainty  about  the  actual  location  of  the  ship 
itself.  The  problem  of  locating  the  target  in  these  conditions  is  known 
as  the  "grid-lock  problem"  for  which  only  a  manual  system  exists.  Refer¬ 
ences  on  this  topic  were  communicated  to  us  late  in  this  project  (McCall, 
1980)  and  include  Tirnan  (1970)  and  Cantrell,  Grindlay  and  Dodge  (1976). 

The  problem  faced  here  is  slightly  different  from  the  grid-lock  problem 
however,  since,  in  our  case,  the  sensor  location  is  known  and  the  uncer¬ 
tainty  about  target  location  is  due  to  sensor  limitations.  Should  the 
uncertainty  about  ship  location  be  somehow  translated  into  target  location 
uncertainty  and  modeled  in  a  manner  similar  to  the  one  presented  here,  the 
method  presented  next  would  also  apply  to  the  grid-lock  problem. 

Assume,  for  example,  that  sensor  1,  characterized  by  a  dispersion  matrix 
Ej  reports  on  an  entity  of  class  C  at  location  Xj  and  that  simultaneously 
sensor  2,  characterized  by  a  dispersion  matrix  Eg.  also  reports  an  entity 
of  class  C  at  Xg  in  the  vicinity  of  x^.  Let  m^  (respectively  nig)  be  the 
true  location  of  the  entity  reported  by  sensor  1  (respectively  sensor  2). 

It  is  desired  to  devise  a  statistical  procedure  allowing  one  to  test 
hypothesis  Hq :  m j  =  mg  (i.e.,  the  two  sensors  are  actually  sensing  the 
same  entity)  versus  m j  ^  nig  (i.e.,  the  two  sensors  are  sensing  different 

entities). 

In  other  words,  consider  two  independent  2-dimensional  non-degenerated 
normal  variables  and  Xg,  i.e.,  with  the  same  notations  as  above, 

Xj/^Ntnij,  Ej)  and  Xg/^W(mg,  Eg)  for  which  samples  Xj  and  Xg,  respectively, 
are  available  and  try  to  devise  a  statistical  procedure  to  test  Hq  against 
defined  above. 
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Note  that  since  Xj  and  X2  are  stochastically  independent,  their  difference 
is  also  normally  distributed.  More  specifically,  X^  -  X2/^(mj  -  mg. 

I  +  z2).  The  problem  is  thus  reduced  to  the  following:  given  a  2-dimen¬ 
sional  normal  variable  X/t?N(m,  l)  for  which  sample  x,  is  available,  devise 
a  procedure  to  test: 

Hq:  m  =  0  against  H^:  m  +  0 

It  is  assumed  that  i  is  definite  positive  since  both  I.  and  i9  are.  It 

1  *  • 

is  well-known  that,  if  HQ  is  true,  the  quantity  x'e  x  is  distributed  as 
chi-square  with  two  degrees  of  freedom.  To  perform  the  test  the  quantity 
x'E~*x  =  Xq5S(2)  is  computed,  and  its  value  compared  to  x  (2),  where  o0 
is  an  acceptable  error  threshold  (e.g.,  aQ  =  10%). 

The  concept  of  employment  for  this  technique  is  as  follows:  when  compar¬ 
ing  an  incoming  sensor  report  with  an  existing  track  record  about  locations 
Xj  and  Xg,  which  are  close  to  each  other,  the  quantity  K  =  (Xj-x^'  (£i  + 
(*■1  ~  *2^  1S  comPuted*  Simultaneously,  for  the  a  priori  level  of  confidence 
l-a0  the  quantity  (2)  is  looked-up  (typically  a0  =  10%  or  5%  for  which 

n  0 

x„  (2)  is  equal  to  4.61  and  5.99,  respectively).  The  system  will  then 
“o 

either  accept  or  reject  hypothesis  is  the  following  manner: 

accept  HQ  if  K  <  (2) 

o 

reject  Hn  if  K  >  x2  (2) 

o 

3.3.3  Track  Similarity.  Track  similarity,  i.e.,  closeness  between  two 
tracks,  can  be  defined  in  a  multitude  of  ways.  First,  the  classes  must 
correlate,  i.e.,  if  one  report  says  'radar'  and  the  other  says  'personnel', 
the  entities  cannot  possibly  be  the  same.  A  contrario,  if  one  says  'three 


tanks'  and  the  other  says  'five  tanks'  the  sensed  entities  can  conceivably 
be  the  same.  Along  the  same  lines,  if  one  report  says  'three  tracked 
vehicles'  and  the  other  says  'five  tanks',  the  corresponding  reports  can 
also  refer  to  the  same  entity.  More  specifically,  if  the  classes  are 
defined  in  a  hierarchical  way,  i.e.,  via  a  tree,  we  will  say  that  there 
is  a  class  discrepancy  between  two  classes  if  the  nodes  which  represent 
these  classes  in  the  tree  do  not  belong  to  the  same  path  from  the  root 
node.  Figure  3-4  portrays  examples  of  class  discrepancies.  Track  proximity 
must  be  defined  along  two  dimensions: 

(1)  The  class  the  entity  belongs  to. 

(2)  The  number  of  elements  in  the  track. 

Since  the  number  of  elements  is  often  the  by-product  of  another  process 
such  as  counting  occurrences  while  watching  a  classifying  unattended 
ground  sensor,  figures  should  be  taken  only  as  indicative  in  many  cases. 

In  addition,  when  a  time  span  is  involved,  attritions  can  occur.  The 
retained  solution  is  the  following:  Define  track  record  T.  which  contains 
n.j  entities  of  class  C.  =  a.  b..  ci  (Dewey  notation  for  3-level  hierarchy). 

We  then  define  the  distance  between  Tj  and  T2  by  d(Tj,T2)  =  WjAj(nj,n£)  + 
W2A2(Cr  C2),  where  Wj  and  W2  are  positive  weights  and  ^  and  a2  are 
distances  in  0*  defined  as  follows: 

Ajfnj.ng)  =  |nx  -  n2| 

a2(Ci»C2)  s  1006(aj,a2)  +  10<s(b^,b2)  +  6(c2,c2) 

where  6  is  Kronecker's  delta  function. 

(0  if  a*6 

6(a,B)  =  < 

i 1  otherwise 
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CLASS  DISCREPANCY 


NO  CLASS  DISCREPANCY 


FIGURES  3-4. 

EXAMPLES  OF  CLASS  DISCREPANCIES 


The  concept  of  employment  of  these  notions  is  as  follows:  After  it  was 
determined  that  two  entities  are  indeed  at  the  same  location,  thus 
implying  that  they  are  very  likely  to  be  the  same,  the  classes  are  checked 
for  a  possible  discrepancy.  If  such  a  discrepancy  is  identified  and  the 
numbers  of  entities  in  the  tracks  are  the  same,  then  a  class  conflict 
exists. 

The  notion  of  track  distance  is  used  for  track  filtering.  When  the 
operator  wants  to  determine  whether  it  is  possible  that  a  moving  entity 
just  sensed  is  actually  an  already  tracked  entity  which  has  moved,  he 
can  filter  out  from  further  consideration  those  tracked  entities  which 
are  very  dissimilar  from  the  entity  under  scrutiny.  This  reduces  the 
number  of  candidates  to  be  considered  and  thus  permits  an  improvement  in 
processing  time. 

3.3.4  Time  Computation  Algorithm.  TCO  capability  number  92,  designated 
"Calculate  time/distance  ratio,"  is  described  as  "the  capability  to 
predict  the  time  needed  to  travel  a  given  distance  over  a  given  terrain 
by  a  given  means."  A  path  is  decomposed  in  n  segments  and  the  time  to 
traverse  the  path  is  given  by: 


T  ■  j/VVi  +  V 

where  i  refers  to  the  1th  leg  of  the  path,  d(  the  leg  length,  s,  the  maxi- 
mum  speed  of  the  entity,  r..  the  reduction  factor  due  to  road  condition 
and  1^  the  loiter  time.  Road  conditions  are  defined  as  excellent,  good, 
poor,  and  very  poor,  and  the  corresponding  reduction  factors  are  1.0,  .75, 
.50,  .25.  d^  is  defined  by  the  formula: 


3-12 


di  sV(xn  -  xi2)  +  (yn  -  yi2) 

where  (x^j,  y^)  and  (x^2*  y^)  are  ^e  UTM  coordinates  of  the  extremities 
of  the  leg. 

The  concept  of  employment  of  this  capability  is  as  follows:  Upon  receipt 
of  a  sensor  report  regarding  a  moving  entity  in  a  location  where  no  enemy 
activity  was  previously  reported,  the  operator  desires  to  check  whether  it 
is  possible  that  the  entity  sensed  is  actually  already  in  the  active  track 
file.  To  check  out  the  possibility  whether  the  entity  sensed  at  location 
(x,y)  can  come  from  elsewhere  requires  that  the  operator: 

(1)  Displays  similar  entities  located  in  the  vicinity  of  (x,y). 

(2)  Ascertains  whether  (x,y)  can  be  accessed  by  any  of  the 
displayed  entities  from  a  geographical  standpoint. 

(3)  Computes  the  time  required  for  the  displayed  units  to  move 
to  location  (x,y). 

(4)  Compares  the  computed  travel  time  to  the  observation  time 
differences. 

Retrieval  of  entities  located  in  the  vicinity  of  (x,y)  will  be  performed 
on  the  basis  of  similarity  as  described  in  3.3.4  above. 


3.3.5  Bayesian  Classification.  The  Bayesian  classification  model  provides 
a  framework  to  make  the  following  classification  decision:  given  m-classes 
specified  in  advance  and  an  observed  entity,  which  of  these  classes  does 
the  entity  belong  to?  Probabilities  ....  irm  that  the  entity  belongs 
to  Cj,  ....  Cm,  respectively  are  available.  Bayes'  strategy  consists  of 
selecting  the  class  which  minimizes  the  expected  loss.  When  a  0-1  loss 


function  is  used,  i.e.,  if  the  subject  incurrs  a  loss  equal  to  1  in  case 
of  a  erroneous  decision  and  a  loss  equal  to  0  in  case  of  a  right  decision, 
this  strategy  is  equivalent  to  minimizing  the  probability  of  error,  i.e., 
to  select  iQ  such  that: 

IT  *  =  maX  7T  • 

’0  i 


Then  the  probability  of  error  Is  P  *  1-ir,.  . 

e  ’o 

In  the  statistical  pattern  recognition  approach  (Duda  &  Hart,  1973),  the 
situation  is  such  that  new  evidence  comes  which  modifies  the  current  a 
priori  probability  estimate  u0.  One  random  variable  can  be  observed  which 
is  related  to  the  classes  via  conditional  probabilities.  Namely,  X,  also 
called  a  feature,  which  can  take  the  values  1,  ...,  K,  can  be  observed 
and  the  probabilities  P(X  =  k|C^)  are  known.  Upon  observation  of  X 
which  yields  a  specific  value  for  X  (e.g.,  X  *  k),  the  probabilities  are 
updated  according  to  Bayes1  formula: 

n  P(X  *  k|CJ 

*i  *  “i - 

l  P(X  «  k | C . )  n° 

1=1  1  1 

A  classification  decision  can  then  be  made  using  wj.  If  the  probability 
of  error  is  higher  than  a  certain  specified  threshold,  the  actual  decision 
is  postponed  and  more  information  is  sought. 

Sensor  reports  are  presented  in  the  form  of  classification  decisions. 

Thus,  in  the  case  of  sensor  reports,  the  feature  observed  is  itself  a 
classification  decision,  thus  requiring  the  knowledge  of  conditional 
probabilities  of  the  type  P(CJC.),  I.e.,  probability  that  the  sensor 


declares  when  the  actual  class  is  Cj.  Certain  sensors  provide  high- 
level  classification  only,  such  as  personnel,  tracked  vehicle,  wheeled 
vehicle.  In  this  case  the  features  are  these  higher-level  classification 
decisions.  Then  the  required  numbers  are  ^high-level  1^*  For  Instance, 
^tracked  vehicle^tank^  falls  in  this  category.  To  require  these 
numbers  is  a  realistic  assumption  as  demonstrated  through  interviews  of 
experts.  Such  numbers  can  be  obtained  through  simulation  or  elicited 
from  experts  having  field  experience.  When  the  elicitation  mode  is 
selected,  assumptions  must  be  made  on  the  type  of  combat  which  is  expected 
and  subjects  selected  whose  background  includes  as  many  as  possible  of  these 
expected  conditions. 

The  concept  of  employment  of  Bayesian  classification  is  as  follows: 

Consider  the  case  where  it  is  determined  that  two  entities  reported  by 
different  sensors  are  close  enough  to  assume  that  they  are  actually  one 
entity.  If  the  classes  reported  are  distinct,  a  classification  conflict 
exists  which  can  be  resolved  via  the  Bayesian  Classification  approach. 

The  priors  are  elicited  from  the  operator  who  is  prompted  by  the  system 
when  such  a  classification  conflict  is  identified.  Then  the  system  uses 
the  conflicting  classification  decisions  provided  by  the  sensors  to 
modify  the  priors,  identify  Bayes1  decision,  and  compute  the  probability 
of  error.  If  the  probability  of  error  is  higher  than  a  certain  prespecified 
threshold,  more  information  will  be  sought  and  Bayesian  classification 
applied  again. 


3.4  Information  Collection  Aiding 

3.4.1  Sensor  Coverage  and  Line-of-Siqht  Calculations.  When  information 
must  be  collected  on  enemy  suspected  presence  at  a  given  location,  it  must 
be  certain  that  the  information  can  Indeed  be  acquired  by  the  available 
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sensors.  This  requires  that  the  location  under  scrutiny  be  within  sensor 
coverage  and  that  no  line-of-sight  limitations  preclude  sensor  employment. 
Thus,  TCO  capabilities  number  67,  designated  as  "Calculate/Display 
Sensor  Placement  and  Coverage"  and  number  91,  "Calculate  Line-of-Sight" 
play  an  important  role  in  the  process  of  selecting  a  sensor  to  gather 
information  about  a  specific  location. 

TCO  capability  number  67,  which  is  described  as  "the  capability  to  display 
the  coverage  which  would  be  provided  (e.g.,  circles/fans)  by  a  proposed 
placement  of  sensors,"  was  viewed  by  TCO  designers  as- a  planning  aid.  It 
can  obviously  be  utilized  after  sensors  have  been  implanted,  as  well. 

The  concept  of  employment  of  these  TCO  capabilities  for  sensor  selection 
is  straightforward.  Once  the  location  under  scrutiny  is  input  to  the 
system,  the  coverages  of  available  sensors  are  computed  using  TCO  capa¬ 
bility  number  67  to  determine  which  sensors  can  acquire  the  target  at 
that  particular  location.  For  those  sensors  which  are  subject  to  line-of- 
sight  limitations  (such  as  ground  surveillance  radars),  TCO  capability 
91  is  called  upon  to  determine  if  a  line-of-sight  exists  between  the  sensor 
and  the  target. 

3.4.2  Information  and  Discrimination  Measures.  When  available  information 
has  been  exhausted  and  uncertainty  still  prevails,  decision  makers 
generally  perform  a  cost-benefit  analysis  to  determine  whether  new  infor¬ 
mation  should  be  acquired.  In  a  case  where  more  than  one  information 
source  can  be  utilized,  decision  makers  who  desire  to  acquire  information 
must,  in  addition,  determine  which  information  source  should  be  utilized. 

The  problems  of  whether  to  acquire  Information  and  which  information 
source  to  use  are  linked  together  via  the  notion  of  informativeness. 
Informativeness  can  be  defined  as  the  ability  to  discriminate  among 
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m 


hypotheses.  If  Pj,  ....  Pm  are  the  respective  probabilities  attached 
by  the  decision  maker  to  m  exhaustive  exclusive  events,  the  following 
measures  of  informativeness  are  available  (Mathai  &  Rathie,  1975): 

-  Shannon's  Entropy:  -  £  P^  Log  Pj 

-  Renyi's  Entropy  of  order  a:  73-  Log  IP?  a  t  1 

1-0  j 

1  a 

-  Havrda  and  Charvat's  Entropy  of  order  o:  — ? - (TP.  -1)  a/  1 

2i_a  -1  i  1 

-  Rathie's  Entropy:  -  £  P? + 1  Log  P^ 

-  Bel  is  and  Guiasu's  Entropy:  -  k  I  u^P^  Log  P^ 

2 

-  Gini's  diversity  index:  1  -  j*  P^ 

In  a  Bayesian  context  with  a  0-1  loss  function.  Shannon's  entropy  possesses 
some  optimality  properties  (Patrick,  1972)  and  its  use  is  therefore 
recommended . 


When  two  sources  of  information  can  be  consulted,  it  is  natural  for  the 
decision  maker  to  select  the  one  which  will  most  increase  their  informative¬ 
ness.  Let  us  define  1^  as  the  net  expected  information  gain  obtained 
through  consultation  with  Information  source  j  which  is  equal  to  the  differ¬ 
ence  between  the  current  measure  of  uncertainty  and  the  expected  posterior 
measure  of  uncertainty  after  consultation  with  information  source  j. 

This  definition  expresses  Ij  an  an  expectation,  and  therefore,  takes  into 
account  the  uncertainty  attached  to  the  actual  information  provided  by 
the  source.  In  a  Bayesian  context,  let  Cj,  ....  Cm  be  exhaustive  mutually 
exclusive  events  whose  a  priori  probabilities  are  irj,  ....  irjjj.  Consultation 
with  Information  source  j  will  yield  the  actual  value  of  a  random  variable 
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Xj.  The  class  probabilities  P(Xj  =  Xj | )  are  supposed  to  be  known,  either 
elicited  from  people  or  obtained  via  simulation  ahead  of  time.  Assume  that 
x.  can  take  values  1,  2 . k.  Then, 

J 

I4  *  f(*°)  -  I  f(i(k)  )  P(X.  =  k) 

J  k=i  J 

where  f (_w )  is  the  information  measure  utilized,  ir*(k)  the  uncertainty 
vector  after  the  observation  of  x.  =  k,  and  P(X.  s  k)  the  probability  that 
information  source  j  will  yield  observation  x.  *  k.  it  (k)  is  obtained 

J 

via  Bayes'  formula: 


and 

P(X.*k)  via 

J 

m 

P(X  .=k)  =  l  PtX.-klCjPtCj 
J  i=1  J  1  1 

Prior  to  consultation  with  any  information  source,  the  operator's  estimate 
of  the  class  probabilities  are  PfC^)  =  can  therefore  be  calculated 

using  this  estimate  since  the  class  conditional  probabilities  P(X^  =  k|C. ) 
are  known. 

The  concept  of  employment  of  this  information  source  selection  aid  is  the 
following.  When  information  is  required  for  classification  of  a  given 
entity  and  several  sensors  can  be  deployed  to  acquire  the  information,  the 
expected  informativeness  Increase  is  computed  for  each  sensor.  This  compu¬ 
tation  Is  performed  using  the  model  described  above  based  on  a  priori  proba¬ 
bilities  elicited  from  the  operator  and  prestored  class  conditional  proba¬ 
bilities.  The  sensor  which  maximizes  this  expected  Increase  is  then 
selected. 


4.  INFORMATION  COLLECTION  AND  CORRELATION  SYSTEM  DESIGN 


4.1  Overview 

i  : 

4.1.1  Local  and  Global  Correlation  Interface.  There  are  two  basic 
system  functions:  (1)  local  correlation  and  (2)  global  correlation.  In¬ 
coming  sensor  reports  are  the  input  to  local  correlation.  The  output  of 
local  correlation  is  a  proposed  track  record  modification  which  is  sent  to 
a  file  referred  to  as  the  track  record  modification  file.  The  inputs 

to  global  correlation  are  the  proposed  track  record  modifications  and  the 
output  is  the  proper  modification  to  the  track  record  file.  Local  correla¬ 
tion  integrates  the  information  available  at  either  Division,  Wing  or  MAF 
level  independently  and  proposes  changes  to  the  existing  track  records. 

The  basic  function  of  global  correlation  is  to  compare  a  proposed  track 
record  modification  (e.g.,  M^)  to  all  other  proposed  track  record  modifi¬ 
cations  and  identify  the  resulting  track  file  modifications  based  on  the 
information  provided  by  all  three  levels.  As  depicted  in  Figure  4-1,  the 
track  record  modification  file  is  organized  as  a  queue  so  that  M^  will  be 
the  element  in  front  of  the  queue.  Such  an  organization  ensures  complete¬ 
ness  since  during  the  local  correlation  the  incoming  information  contained 
in  sensor  reports  is  compared  to  the  information  received  earlier.  During 
global  correlation,  however,  it  is  compared  to  the  information  received 
later  while  it  was  in  the  queue.  In  addition,  modelling  and  thus  analysis 
of  the  system's  behavior  can  be  performed  using  the  framework  of  queueing 
theory.  Such  an  analysis  is  provided  in  Appendix  E. 

An  overview  of  the  local  and  global  correlation  subsystems  is  presented 
in  the  next  two  sections. 

Although  some  of  the  modules  in  both  local  correlation  and  global  correla¬ 
tion  systems  involve  the  same  decision  subprocesses,  due  to  Input/output 
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requirements,  there  are  basic  differences  in  the  design  of  most  of  the 
modules.  However,  there  are  some  identical  modules  used  in  both  systems 
for  which  only  one  description  is  given. 

4.1.2  Local  Correlation.  In  this  section  an  overview  of  the  local 
correlation  system  function  is  presented.  The  selected  design  is  portrayed 
in  Figure  4-2.  It  makes  explicit  the  concept  shown  previously  in  Figure  3-2 
by  showing  the  modules  which  are  within  the  system  boundaries,  the  files 
used,  the  external  resources  on  which  the  system  draws,  the  internal 
connections  and  the  interactions  with  the  environment. 

The  local  correlation  module  is  activated  upon  receipt  of  a  sensor  report 
which  contains  such  information  as  the  location  and  class  of  the  entity 
sensed  (E),  the  sensor  (specifically  sensor  type  and  location),  the  time 
of  the  sighting  and  the  number  of  elements  identified.  First  the  relia¬ 
bility  score  for  this  report  is  computed  using  the  sensor  type  and  the 
sensor  location.  The  sensor  location  is  retrieved  from  the  sensor  avail¬ 
ability  file  and  is  used  in  conjunction  with  the  terrain  characteristics 
file  and  the  enemy  activity  file  to  determine  the  environmental  conditions 
which  surround  the  sensor.  Concurrently,  the  vicinity  check  module  is 
activated  with  the  entity  location  and  the  sensor  type  as  inputs.  This 
module  checks  for  entities  which  are  in  the  active  segment  of  the  track 
record  file  and  which  could  be  the  same  as  the  entity  involved  in  the 
sensor  report  just  received.  The  output  of  this  vicinity  check  module  is 
the  list  (possibly  empty)  of  E-related  tracks.  If  there  are  any  E-related 
tracks  in  the  active  segment  of  the  track  record  file,  an  action  can  be 
taken  with  regard  to  the  received  sensor  report.  If  the  entity  belongs 
to  a  non-moving  class,  a  new  track  is  created.  If  the  entity  is  a  mover 
it  must  be  determined  whether  to  create  a  new  track  or  update  an  existing 
track,  i.e.,  determine  whether  or  not  this  move  is  actually  an  already 
tracked  entity  which  moved.  In  support  of  this  human  function  the  system 


executes  the  track  record  filtering  module  which  filters  out  irrelevant 
tracks.  It  also  displays  on  the  DSD  terminal  the  entities  which  are 
similar  (in  the  sense  defined  in  3.3.3)  to  the  entity  just  reported. 

During  the  execution  of  the  mover  correlation  module  the  operator  then 
interacts  with  TCO  capabilities  such  as  DSD  with  map  background  showing 
natural  routes  of  penetration  and  time/distance  algorithm  which  computes 
the  time  it  takes  for  an  entity  to  traverse  a  distance.  Upon  completion 
of  the  mover  correlation  module  a  decision  is  made  with  regard  to  the 
track  modification  action(s)  to  be  taken. 

When  the  E-related  track  list  is  not  empty  the  case  is  a  little  more 
complicated.  In  this  case,  the  E-related  tracks  together  with  the 
sensor  report  are  checked  for  a  class  discrepancy.  If  no  class  discrepancy 
is  found  the  information  contained  in  these  E-related  tracks  must  be 
aggregated  with  the  information  contained  in  the  sensor  report  to  define 
an  aggregated  location  and  to  compute  a  reliability  score.  Also  the 
E-related  tracks  must  be  removed.  The  situation  is  now  the  same  as  if 
the  E-related  track  list  was  empty.  The  aggregated  information  is  used 
to  identify  the  proper  action,  i.e.,  creation  of  a  new  track  or  activation 
of  the  mover  correlation  module.  If  a  class  conflict  is  identified 
among  members  of  the  E-related  track  list  (including  the  sensor  report 
itself)  the  conflict  must  be  resolved.  First  the  various  reliability 
scores  are  computed  and  if  a  large  discrepancy  between  these  scores  exists 
the  less  reliable  E-related  tracks  (or  the  sensor  report  itself)  are 
deleted.  If  a  conflict  still  exists,  or  if  data  do  not  permit  this 
deletion,  the  classification  module  is  activated.  This  module  aggregates 
the  conflicting  classification  decisions  by  determining  Bayes  classifica¬ 
tion  decision  and  computing  the  corresponding  probability  of  error. 

For  these  computations  inputs  from  the  sensor  characteristics  file  are 
used.  If  the  probability  of  error  is  below  a  prespecified  threshold, 
the  Information  aggregation  module  is  activated  and  the  system  proceeds 
as  when  the  E-related  track  record  list  is  empty. 


If  the  probability  of  error  is  unacceptably  high,  more  information  must 
be  gathered.  For  this  purpose  a  sensor  must  be  deployed  thus  requiring 
the  selection  of  the  most  informative  among  available  sensors.  For  this 
selection  the  system  uses  inputs  from  the  sensor  characteristics  file, 
the  enemy  activity  file  and  the  sensor  availability  file,  and  draws  on 
TCO  capabilities  sensor  coverage  calculations  and  line-of-sight  calcula¬ 
tions.  After  the  proper  sensor  has  been  selected,  a  cue  message  is  sent 
to  the  manager  of  this  sensor.  The  result  is  the  receipt  of  a  response 
to  the  request  which  is  input  as  a  new  sensor  report.  New  information 
will  eventually  permit  resolution  of  the  class  conflict  and  upon  this 
resolution  the  situation  will  be  the  same  as  when  the  E-related  track 
list  is  found  empty,  i.e.,  the  system  proceeds  toward  creating  a  new 
non-mover  track  or  activating  the  mover  correlation  module. 

The  output  of  the  local  correlation  module  is  a  proposed  modification  or 
set  of  modifications  to  the  track  record  file.  These  modifications  fall 
into  two  general  categories:  creation  of  a  new  track  and  updating  or 
deletion  of  an  existing  track.  Proposed  modifications  to  the  track  record 
file  are  formatted  in  a  manner  which  facilitates  the  identification  of 
conflicts  between  proposed  track  modifications. 

4.1.3  Global  Correlation.  This  section  presents  an  overview  of  the 
global  correlation  system  function.  The  selected  design,  portrayed  in 
Figure  4-3,  makes  explicit  the  concept  shown  previously  in  Figure  3-3. 

The  proposed  track  file  modification,  which  is  In  front  of  the  track  re¬ 
cord  modification  queue,  will  be  compared  to  all  other  proposed  modifica¬ 
tions  In  the  queue.  As  a  result  of  this  comparison,  one  of  the  two  actions 
will  be  taken:  Implement  or  delete  Mf.  Hence,  Mf  is  compared  to  the 
current  Mc  in  the  queue.  If  is  superseded  by  one  Mc,  the  decision  Is 
then  made  to  delete  and  global  correlation  will  proceed  with  the  pro¬ 
posed  track  record  modification  which  is  now  in  front  of  the  queue.  If 
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supersedes  or  does  not  conflict  with  any  of  the  other  elements  of  the 
queue  then  the  decision  is  made  to  implement  M^.  It  is  assumed  that  the 
elements  of  the  track  record  modification  queue  are  formatted  in  a  standard 
way  suitable  for  automatic  handling. 

Upon  inspection  of  and  Mc  the  modification  conflict  identification 
module  automatically  identifies  any  conflict  together  with  the  conflict 
type.  This  can  be  done  by  consultation  with  the  conflict  type/action 
table  which  contains  an  exhaustive  list  of  all  possible  conflicts.  The 
processes  which  are  involved  in  modification  conflict  identification  are 
basically  the  same  as  in  class  conflict  identification  since  the 
following  questions  must  be  answered  in  the  present  case  as  well:  (1) 
can  the  two  entities  under  scrutiny  actually  be  the  same?  and  (2)  is 
there  a  class  discrepancy?  If  no  conflict  is  identified,  the  next  Mc 
in  the  queue  is  taken  and  compared  to  Mf.  If  a  conflict  is  identified, 
it  must  be  resolved.  First  the  reliability  index  computation  module  is 
activated  to  determine  if  a  reliability  discrepancy  exists.  If  a  signi¬ 
ficant  difference  in  reliability  scores  does  exist,  the  less  reliable 
modification  is  deleted  and  proper  action  is  taken,  i.e.,  either  delete 
or  take  next  Mc  in  the  queue.  If  no  reliability  discrepancy  can  be 
identified,  more  information  must  be  gathered  to  resolve  the  conflict. 
However,  if  the  entity  is  a  mover  and  a  substantial  amount  of  time  has 
already  elapsed  due  to  the  local  correlation  process  and  the  subsequent 
waiting  in  the  queue,  the  entity  has  possibly  moved  elsewhere  and  there¬ 
fore  indiscriminately  requesting  more  sensor  information  is  not  meaningful 
due  to  the  uncertainty  about  the  present  entity  location.  Thus,  if  the 
time  elapsed  is  longer  than  a  specified  threshold  the  operator  is  called 
upon.  He  then  executes  the  modification  selection  module,  i.e.,  makes 
a  decision  with  regard  to  the  next  action.  As  the  next  action,  he  has 
the  option  of  requesting  more  information,  i.e.,  to  call  the  confirming 
sensor  selection  module.  This  module  draws  its  label  from  Its  function 
which  is  to  select  the  best  sensor  to  confirm  the  presence  of  an  entity 


of  a  certain  class  at  a  certain  location.  With  regard  to  which  location(s) 
to  focus  on,  the  conflict  type/action  table  provides,  for  each  conflict 
type,  the  proper  information  gathering  action.  The  locations  in  which 
the  entities  were  last  seen  are  also  used.  The  available  sensors  which 
can  acquire  the  entity  are  matched  against  the  sensor  characteristics 
file  which  contains  the  list  of  sensor  types  prioritized  on  the  basis  of 
appropriateness  for  confirmation.  Once  the  best  sensor  has  been  selected, 
a  sensor  cue  message  is  sent.  Upon  receipt  of  the  requested  information 
the  operator  selects  the  proper  action.  This  results  in  an  implementa¬ 
tion  decision  on  M^. 

4.2  Local  Correlation 

4.2.1  Reliability  Assessment. 

Purpose:  This  module,  portrayed  in  Figure  4-4,  automatically  computes 

the  reliability  score  of  a  sensor  report. 

Input:  A  sensor  report  (the  required  information  are  (1)  sensor  type 

and  (2)  sensor  location). 

Output:  The  reliability  score  which  will  be  attached  to  the  sensor 

report. 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Enemy  Activity  File  (external) 

Terrain  Characteristics  File  (external) 


Functions:  Using  the  sensor  type  as  input,  the  system  retrieves  from  the 
sensor  characteristics  file  the  maximum  localization  and 
classification  scores  c^3*  and  a£ax.  Concurrently,  using  the 
sensor  report  which  contains  the  information  source  the 
system  retrieves  the  sensor  location  from  the  sensor  availability 
file  (the  sensor  availability  file  contains  the  list  of  all 
available  sensors  including  their  type  and  location  and  the 
collection  agency  which  manages  them).  The  sensor  location 
together  with  the  enemy  activity  file  and  the  terrain  charac¬ 
teristics  file,  are  used  to  define  the  environmental  conditions 
at  sensor  location.  Using  the  defined  environmental  character¬ 
istics  as  input,  the  score  reduction  factors  pl  and  pc  are 
retrieved  from  the  sensor  characteristics  file.  The  localiza¬ 
tion  and  classification  scores  are  then  computed  using  the 
formul as : 

„  -  max  .  „  _  max 
rL  PL  aL  and  rC  PC  aC 

The  individual  scores  are  then  aggregated  into  a  single  number 
using  the  formula  R  »  (r^  +  r^)/2. 

4.2.2  Vicinity  Check. 

4.2.2. 1  Overview. 

Purpose:  This  module,  portrayed  in  Figure  4-5,  Identifies  the  list 

(possibly  empty)  of  tracks  which  are  very  likely  to  be  the 
same  as  a  given  entity  E. 


Input: 


An  entity  E  just  sensed.  The  specific  Inputs  are: 
Entity  location 
Sensor  type 
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Functions  and  files  outside  dotted 
lines  provided  for  in  the  TCO  concept. 


FIGURE  4-5. 
VICINITY  CHECK 


Output: 


The  list  of  E-related  tracks. 


Files:  Active  Track  File  Segment  (external) 

Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Functions:  This  module  is  made  of  two  modules:  (1)  close  track  identi¬ 
fication  and  (2)  significantly  close  tracks  identification. 

These  two  modules  operate  in  sequence. 

4. 2. 2. 2  Close  Tracks  Identification 

Purpose:  This  module  defines  the  active  tracks  which  are  in  the  vicinity 

of  an  entity  E  sensed  by  a  sensor  of  a  given  type  (Figure  4-6). 

Input:  Sensor  type 

Entity  location 

Output:  The  list  of  tracks  in  the  vicinity  of  E. 

Functions:  A  vicinity  area  is  defined  as  a  circle  of  radius  RQ  centered 

at  L.  Rq  is  a  threshold  function  of  the  uncertainty  associated 
with  the  sensor  type.  It  is  retrieved  from  the  sensor  character¬ 
istics  file.  The  track  records  in  the  active  track  record 
file  which  are  at  a  distance  less  than  R,  from  E  are  then 
identified  thus  yielding  the  list  (possibly  emply)  of  the 
tracks  close  to  E. 


4. 2. 2. 3  Significantly  Close  Tracks  Identification 


Purpose:  This  module  which  is  portrayed  In  Figure  4-7  identifies, 

among  the  tracks  close  to  E,  those  which  are  significantly 
close,  l.e.,  which  refer  to  the  same  entity  with  a  proba¬ 
bility  higher  than  an  operator-specified  threshold. 


4-13 


RECORD  IN 
CLOSE 

TRACK  LIST 


Input:  location  of  E  and  Sj  the  sensor  which  acquired  E; 

x.j  location  reported  by  sensor  s^  for  track  record  i  in  the 
vicinity  of  E. 

Output:  The  set  of  E-related  tracks. 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Functions:  The  distance  check  module  is  applied  to  all  combinations 

(.*1»  sj)  I  f°r  *  in  the  close  track  record  list.  If 

track  record  i  passes  the  distance  check,  i.e.,  if  track 
record  i  is  significantly  close  to  E,  it  is  put  in  the  set 
of  E-related  tracks. 

4. 2. 2. 4  Distance  Check 

Purpose:  This  module,  depicted  in  Figure  4-8,  checks  if  two  sensors 

could  have  sensed  the  same  entity. 

Input:  Two  observed  locations  jtj  and  x^»  and 

The  respective  sensors  Sj  and  s..  which  acquired  the  corres¬ 
ponding  entities. 

Output:  A  decision  whether  the  entities  are  at  the  same  or  distinct 

locations. 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 


FIGURE  4-8. 
DISTANCE  CHECK 


Functions: 


4.2.3 

Purpose: 

Input: 

Output: 

Files: 

Functions: 


The  sensor  dispersion  characteristics  Ej&Eg  are  defined  from 
the  sensor  characteristics  file  and  the  sensor  availability 
file.  If  Eq  is  the  dispersion  matrix  of  a  given  sensor  and  9 
is  the  sensor  orientation  we  have: 

(cosG  sin0\ 

-sin0  cos0/ 

The. quantity  K  =  (x^  -  Xg)'  (Ej  +  Lg) ” ^ ( x_i  -  1S  then 
computed  and  compared  to  (2) .  where  aQ  is  a  predicted 
maximum  acceptable  percentage  of  error.  The  decision 
immediately  follows. 

Reliability  Index  Computation 

The  purpose  of  this  module,  portrayed  in  Figure  4-19,  is  to 
compute  an  index  which  reflects  discrepancies  between 
reliability  scores. 

A  set  of  numbers  Rj,  ...,  Rp  between  0  and  1  which  represent 
reliability  indices. 

A  number  which  reflects  discrepancies  between  n  numbers. 

None. 

The  maximum  and  minimum  among  the  R^'s  are  computed  thus 
allowing  computation  of  the  range.  The  simple  average  of 
the  scores  is  also  computed.  The  dispersion  characteristic 
0  =  range/average  is  then  computed  as  the  discrepancy 
indicator. 
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FIGURE  4-9. 
RELIABILITY 


INDEX  COMPUTATION 
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4.2.4  Classification 


i 


4. 2. 4.1  Overview 

Purpose:  This  module,  which  is  portrayed  in  Figure  4-10,  implements 

Bayes'  strategy  and  computes  the  probability  of  error  corres¬ 
ponding  to  Bayes'  decision. 

Input:  A  set  of  conflicting  classification  decisions  and  the  corres¬ 

ponding  sensor  types. 

Output:  Bayes'  classification  decision  and  the  corresponding  probability 

of  error. 

Files:  Sensor  Characteristics  File  (internal) 


Functions:  The  operator  is  first  prompted  to  assign  prior  probabilities 
to  the  possible  classification  decisions  which  can  be  made 
concerning  the  entity  under  scrutiny.  These  elicited  priors 
may  be  equal.  Using  these  prior  probabilities  the  system 
applies  the  Bayesian  updating  module  and  uses  all  the  classi¬ 
fication  decisions  and  input  from  the  sensor  characteristics 
file  to  determine  the  a  posteriori  class  probabilities.  The 
Bayesian  classification  module  is  then  activated  thus 
resulting  in  a  classification  decision  y  and  a  probability  of 
error  Pg. 


4.2. 4.2  Bayesian  Updatinc 


Purpose:  This  module,  which  is  portrayed  in  Figure  4-11,  updates  a 

priori  probabilities  to  take  into  account  new  information 
using  Bayes'  formula. 


1  » 
COMPUTE  A,- 

P«WClK 

N  a2 
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FIGURE  4-11. 
BAYESIAN  UPDATING 


Input:  A  priori  probabilities 

Classification  decision  C  and  the  corresponding  sensor  type. 

Output:  A  posteriori  probabilities. 

Files:  Sensor  Characteristics  File  (internal). 

Functions:  Using  the  sensor  type  as  an  input,  the  class  conditional 

probabilities  | C^ )  are  retrieved  from  the  sensor 

characteristics  file  and  Bayes'  formula  applied  thus  yielding 
the  a  posteriori  probabilities. 


4. 2. 4. 3  Bayesian  Classification 


Purpose:  This  module  which  is  portrayed  in  Figure  4-12  determines 

Bayes'  decision  and  computes  the  corresponding  probability  of 
error. 


Input:  The  possible  decisions  Cj,  ....  C^  and  the  corresponding 

probabilities  it ^ ,  ....  ir^. 

Output:  Bayes1  classification  decision 

Probability  of  error 

Files:  None. 


Functions:  Bayes'  decision  which  minimizes  the  probability  of  error  is 
determined  by  maximizing  (since  if  i  is  selected  the 
probability  of  error  is  Pfi  *  1-ir^ ) . 
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4.2.5  Sensor  Selection 


4.2.5. 1  Overview 

Purpose:  The  purpose  of  this  module  which  is  portrayed  in  Figure  4-13 

is  to  define  the  best  (i.e.,  the  most  informative)  available 
sensor. 

Input:  K  possible  classification  decisions  and  the  corresponding 

probabilities. 

The  entity  Location  L. 

Output:  The  best  available  sensor 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Enemy  Activity  File 

Functions:  First  the  list  of  applicable  sensors,  i.e.,  the  list  of  the 
sensors  which  can  indeed  acquire  the  entity  located  at  L  is 
defined.  These  sensors  are  then  prioritized  by  order  of 
informativeness  according  to  their  type  during  the  execution 
of  the  sensor  prioritization  module  thus  resulting  in  the 
determination  of  the  best  available  sensor. 


4. 2. 5. 2  Applicable  Sensors  Definition 


Purpose:  The  purpose  of  this  module,  which  is  portrayed  in  Figure  4-14, 

is  to  determine  the  sensors  which  can  acquire  information  at 
a  given  location. 


Functions  and  files  outside  dotted 
lines  provided  for  in  the  TCO  concept. 


FIGURE  4-13. 
SENSOR  SELECTION 
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Input: 


A  location  l 


Output:  The  list  of  sensors  which  can  acquire  information  at  location  L. 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Enemy  Activity  File  (external) 

Functions:  Using  location  L  as  an  input  the  system  first  defines  the 
relevant  sensors  by  checking  out  all  available  sensors  to 
determine  whether  they  can  cover  location  L.  To  perform  this 
function  the  system  draws  on  the  TCO  capability  to  compute 
sensor  coverages.  From  the  list  of  available  sensors  those 
which  are  subject  to  line-of-sight  and  other  limitations  are 
deleted.  This  is  performed  by  application  of  the  TCO  capa¬ 
bility  to  compute  the  line-of-sight  between  two  points  and 
on  the  enemy  activity  file  to  determine  if  the  enemy  can  pre¬ 
vent  acceptable  sensor  operation. 

4. 2. 5. 3  Sensor  Prioritization 

Purpose:  This  module  which  is  described  in  Figure  4-15,  prioritizes 

sensors  by  decreasing  order  of  informativeness. 

Input:  A  prior  class  probabilities  jr° 

Sensor  type  list 

Output:  Prioritized  list  of  sensor  types 

Files:  Sensor  Characteristics  File  (internal) 


Functions:  Using  sensor  type  S  the  class  conditional  probabilities 

Pc(C|C<)  are  retrieved  from  the  sensor  characteristics  file. 

j  j  i 

This  permits  the  computation  of  the  updated  class  probabili¬ 
ties  if  a  sensor  of  type  S  is  used  and  C.  is  observed.  The 

J 

information  increase  expected  from  usage  of  a  type  S  sensor 
is  then  computed.  This  permits  prioritization  of  the  sensor 
types  by  decreasing  order  of  informativeness. 

4.2.6  Information  Aggregation 

Purpose:  This  module,  which  is  portrayed  in  Figure  4-16,  aggregates 

sensor  reports  about  a  common  entity  into  a  common  location. 
It  also  computes  the  aggregated  localization  score. 

Input:  Sensor  reports.  The  specific  information  are: 

The  entity  location  reports,  and 
The  sensor  used. 


Output:  Aggregated  location 

Localization  score 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (external) 

Functions:  The  module  computes  the  simple  average  of  the  reported  loca¬ 
tions  as  the  aggregated  location.  Concurrently,  the  module 
computes  the  dispersion  matrices  as  described  in  4. 2. 2. 4  and 
determines  the  simple  average  of  these  matrices  to  finally 
compute  the  aggregated  localization  score. 


4.2.7  Track  Record  Filterin' 


Purpose:  This  module  which  is  portrayed  in  Figure  4-17  filters  out  track 

which  are  dissimilar  from  a  given  entity. 

Input:  An  entity  E  defined  by  a  set  of  data  (location,  class,  number 

of  elements,  time  of  observation) 

Output:  Candidate  tracks  (similar  to  the  input  entity). 

Files:  Track  Record  File  (external) 

Class/Speed  File  (external) 

Functions:  First  the  system  retrieves  those  track  records  which  are  at  a 
distance  less  than  DQ  from  the  entity  E.  Then  the  entity 
class  and  the  number  of  elements  observed  are  used  to  compute, 
for  each  of  the  retrieved  tracks,  a  degree  of  similarity  with 
E.  Only  those  tracks  whose  degrees  of  similarity  with  E 
are  higher  than  an  a  priori  specified  threshold  are  kept  for 
further  processing.  For  each  of  the  remaining  tracks  the 
corresponding  average  speeds  which  are  stored  by  class  in  the 
class/speed  file  are  retrieved.  This  allows  the  computation 
of  an  average  distance  that  the  tracked  entity  could  have 
traversed  in  straight  line  during  the  observed  time  difference. 
If  this  distance  is  smaller  than  the  actual  distance  between 
the  track  record  and  the  entity  the  track  record  is  filtered 
out.  This  results  in  a  list  of  possible  mover  candidates 
which  are  similar  to  E  and  could  have  been  reported  as  E. 


Functions  and  files 
outside  dotted  lines' 
provided  for  in  the 
TCO  concept. 


FIGURE  4-17. 

TUCK  RECORD  FILTERING 
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4.3 


Global  Correlation 


4.3.1  Modification  Conflict  Identification 

Purpose:  This  module,  which  is  portrayed  in  Figure  4-18,  determines  the 

conflict  type  (no  conflict  if  type  =  0)  between  two  proposed 
track  file  modifications.  It  is  assumed  that  track  file 
modifications  are  expressed  in  the  universal  format  [0 | T] 
which  stands  for:  substitute  9  for  T  where  9  is  a  new  track 
(9  can  be  equal  to  the  void  set)  and  T  is  an  existing  track 
(T  also  can  be  equal  to  the  void  set). 

Input:  Two  proposed  track  file  modifications. 

Output:  Conflict  Type  number 

Files:  Sensor  Characteristics  File  (internal) 

Sensor  Availability  File  (internal) 

Functions:  Using  the  sensors  which  yield  track  records  9^  and  9C,  the 
vicinity  area  is  defined  (as  a  function  of  the  sensors 
employed)  as  described  in  4. 2. 2. 2.  If  the  locations  repre¬ 
sented  by  9^  and  9C  are  not  in  the  vicinity  of  each  other 
the  locations  represented  by  9^  and  9c  are  distinct.  If 
these  locations  are  in  the  vicinity  of  each  other  the 
distance  check  (same  as  4. 2. 2. 4)  is  applied  in  order  to 
determine  if  these  locations  are  distinct.  If  a  class 
discrepancy  is  identified  the  conclusion  is  that  the  entities 
are  distinct.  Figure  4-18  shows  the  logic  of  modification 
conflict  identification.  This  logic  has  been  designed  using 
the  catalogue  of  all  possible  conflicts  as  a  basis.  Eight 
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conflict  types  were  identified.  They  are  graphically  portrayed 
in  Figure  4-19.  For  instance,  in  a  type  I  conflict  one  center 
declares  that  the  mover  located  at  LI  moved  to  L2  while  the 
other  declares  that  this  mover  stayed  at  LI  and  that  the 
sighting  which  just  occured  at  L2  corresponds  to  a  new  entity. 
Table  4-1  depicts  typical  conflict  track  record  modifications. 
These  modifications  illustrate  those  portrayed  graphically  in 
Figure  4-19.  Note  that  the  three-digit  numbers  correspond  to 
existing  track  identifiers  while  NEW  corresponds  to  a  new  track 
which  did  not  receive  an  identifier  yet.  Identifying  numbers 
are  provided  only  after  the  decision  is  made  to  actually 
implement  the  corresponding  modification. 


4.3.2  Confirming  Sensor  Selection 


Purpose:  This  module  which  is  portrayed  in  Figure  4-20,  determines  the 

best  confirming  sensor  to  resolve  a  modification  conflict  of 
a  given  type. 


Input:  The  two  conflicting  modifications. 

The  conflict  type. 


Output:  The  best  available  confirming  sensor. 


Files:  Sensor  Characteristics  File  (internal) 

Sensor  Type/Action  Table  (internal) 
Sensor  Availability  File  (external) 
Enemy  Activity  File  (external) 


The  conflict  type/action  table  defines  information  gathering 
strategies.  It  is  portrayed  in  Table  4-2  which  shows,  for  each 


TABLE  4-1 


Type  I 

Type  II 

Type  III 

Type  IV 

Type  V 

Type  VI 

Type  VII 


TYPICAL  CONFLICTING  TRACK 
RECORD  FILE  MODIFICATIONS 


[ ( 125 | L2 | ) I ( 125 } LI | ... ) J 
C(MEW|12|...)|  0  ] 

[ ( 132 1 L2 1 . . . ) | ( 132 1 11 ] . . . ) ] 
[(132|L3| . ..)| (132|L1| ... )] 

[(127|L2| . . . ) | (127|L1| . . . )] 
C(142|L2| . . . ) I (142|L2| . . . )] 

C  9  | ( 175 | LI | . . . )] 

C(175|L2|...)|(I75|LI| ...)] 

C( 187  j  L2 1 .. . ) | (187 1 LI | . . . )] 
C(NEW|L2|.,.)|  9  ] 

[(257 | 12 | . . . ) | (257 | LI | . . . )] 
[(257 | 13 | . • . )| (257 | LI | .. . )] 

[(177|L2| . . . )| (177 | LI | . . . )] 
[ (245 | L2 | . • . ) | (245|L3| .. . )] 

[  0  |(222|ll| ... )] 

[(222| L2| . . . ) | (222 | LI | .. . )] 
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FIGURE  4-20, 

CONFIRMING  SENSOR  SELECTION 
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conflict  type,  the  conflict  source  and  the  conflict  resolving 
information  (the  reader  is  referred  to  Figure  4-19  which 
provides  a  graphic  portrayal  of  the  various  conflict  types, 
for  the  meaning  of  LI,  L2  and  L3). 

Functions:  This  module  is  itself  composed  of  two  modules  to  be  executed 

in  sequence.  Using  the  conflict  type  as  an  input  the  available 
sensors  definition  module  consults  the  conflict  type/action 
table  to  determine  which  location(s)  to  focus  on  for  infor¬ 
mation  gathering.  From  then  on,  the  applicable  sensors  defi¬ 
nition  module  performs  exactly  as  described  in  4. 2. 4. 2.  The 
output  of  this  module  is  the  list  of  sensors  which  can  acquire 
the  desired  information.  To  determine  the  best  sensor  the 
sensor  characteristics  file  is  consulted,  since  this  file 
contains  a  list  of  sensor  types  prioritized  by  decreasing 
order  or  appropriateness  for  confirmation  of  the  presence  of 
an  entity  of  a  given  class.  This  consultation  immediately 
yields  the  sensor  which  is  best  suited  for  the  job. 

4.4  Summary 


In  this  chapter  we  have  provided  a  detailed  design  for  the  Information 
Collection  and  Correlation  system  including  functions,  flow-charts  and 
diagrams.  A  number  of  human  judgments  are  required  for  proper  system 
function.  Most  of  these  judgments,  such  as  significance  thresholds,  are 
obtained  prior  to  the  actual  use  of  the  system.  They  are  stored  in  ade¬ 
quate  files  and  can  possibly  be  changed.  Other  judgments  are  obtained 
on-line  when  the  system  is  used.  Four  of  the  ICC  system  modules  require 
human  judgments.  They  are  (1)  reliability  assessment,  (2)  significantly 
close  track  definition,  (3)  classification,  and  (4)  track  record  filtering. 
In  (1),  human  judgments  are  required  to  a  priori  define  classes  of  environ¬ 
mental  characteristics  and  the  corresponding  score  reduction  factors. 


TABLE  4-2 


CONFLICT  TYPE/ACTION  TABLE 


Confl  ict 
Type 

Conflict  Source 

Conflict  Resolving  Information 

Type  I 

Questioned  presence  of 
an  entity  (a  mover)  of 
class  C  in  U 

Confirmation  of  the  presence 
or  absence  of  an  entity  of 
class  C  in  LX 

Type  II 

The  same  entity  (a  mover 
of  class  C)  cannot  be 
in  two  different  places 

12  &  13 

Confirmation  of  the  presence 
or  absence  of  an  entity  of 
class  C  in  L2  &  L3 

Type  III 

The  same  entity  cannot 
come  from  two  different 
places 

Confirmation  of  the  presence 
or  absence  of  an  entity  of 
class  C  in  LI  &  L3 

Type  IV 

Questioned  presence  of 
an  entity  (a  mover  of 
class  C)  in  12 

Confirmation  of  the  presence 
or  absence  of  an  entity  of 
class  C  in  L2 

Type  V 

Questioned  presence  of 
an  entity  (non-mover  of 
class  C*)  in  LI 

Confirmation  of  the  presence 
or  absence  of  a  non-mover  of 
class  C’  In  LI 

Type  VI 

The  same  entity  (non¬ 
mover  of  class  C‘)  cannot 
be  at  two  places 

Confirmation  of  the  presence 
or  absence  of  a  non-mover  of 
class  C*  in  L2  4  L3 

Type  VII 

The  entity  sighted  in  one 
place  cannot  have  been 
in  two  different  places 
earlier 

Confirmation  of  the  presence 
or  absence  of  a  non-mover  of 
class  C*  in  LI  or  L3 

Type  VIII 

An  entity  which  is  non- 
moving  cannot  leave' 

Confirmation  of  the  presence 
or  a  non-mover  of  class  C* 
in  L2 

Also  a  priori  defined  (obtained  by  a  mixture  of  calculations  and  human 
judgments)  are  the  maximum  localization  and  classification  scores.  In 
(2),  an  operator-specified  significance  threshold  is  required  and  stored 
ahead  of  time.  In  (3),  both  a  significance  threshold  and  class-conditional 
probabilities  elicited  off-line  from  experts 

files,  are  required.  Also  required  in  (3)  are  a  priori  class  probabilities 
elicited  on-line  from  operators.  In  (4),  two  thresholds  are  requested 
off-line  from  the  operator  and  stored  prior  to  activation  of  the  system. 


Finally,  it  should  be  mentioned  that  the  interaction  between  the  system  and 
its  operators,  i.e.,  the  information  displays,  must  be  defined.  This 
will  constitute  the  next  step  in  the  system  design. 


5.  CONCLUSION 


We  have  presented  an  Information  Collection  and  Correlation  (ICC)  system 
which  supports  the  production  of  combat  information  correlation  in  amphibious 
operations.  The  support  system  was  conceptualized  and  a  specific  design 
was  provided.  The  concept  selected  followed  from  a  system  analysis  of  the 
correlation  functions.  Using  well-established  mathematical  techniques, 
these  functions  were  modelled  and  aiding  modules  were  designed. 

The  ICC  Support  System  does  not  introduce  extraneous  functions  to  the 
present  information  collection  and  correlation  processes.  The  system 
merely  makes  explicit  the  required  functions  and  their  underlying  mental 
processes.  Without  the  support  system,  these  processes  are  often  performed 
crudely,  mainly  in  linguistic  or  fuzzy  terms.  The  system,  however,  pro¬ 
vides  a  formal  quantitative  scheme  to  aid  the  performance  of  the  same 
processes  more  accurately  or  automatically.  Thus  the  formalism  which  is 
inherent  to  the  system  does  not  introduce  any  additional  complexity. 

The  ICC  Support  System  is  directly  implementable  within  the  framework  of 
TCO  and  interacts  with  a  series  of  its  capabilities.  The  requirement 
analysis  indicated  that  the  system  can  indeed  be  implemented  in  the  TCO 
simulated  environment. 
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APPENDIX  A 
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MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  HURIAU  Of  STANDARDS  1<K>*  A 


A.l  INTRODUCTION 


This  appendix  documents  the  application  of  the  Marine  Decision  Taxonomy 
to  decision  aid  selection  for  the  Tactical  Combat  Operations  System  (TCO). 
During  a  working  session  at  MCTSSA/TSCR8,  it  was  concluded  that  such  an 
application  will  provide  necessary  means  for  the  design/ selection  of 
proper  decision  aids  for  TCO.  Therefore,  the  activities  reported  here 
were  added  to  the  second-year  effort  of  the  Taxonomy  program. 

In  order  to  apply  the  methodology  developed  during  the  first  year  program, 
the  taxonomic  approach  was  tailored  to  the  specific  needs  of  TCO.  TCO- 
supported  decision  tasks  were  identified  and  classified  using  the  decision- 
task  descriptors  defined  during  the  first-year  program.  The  matching 
principles  were  applied,  and  aiding  scores  were  defined.  Aiding  scores 
represent  the  effectiveness  of  each  decision-aiding  technique  with  respect 
to  each  specific  TCO-supported  decision  task.  Importance  weights  of  the 
decision  task  were  then  assessed  through  structured  expert  interviews. 

Based  on  these  data,  the  average  aiding  score  for  each  decision-aiding 
technique  was  computed,  thus  providing  a  systematic  framework  for  selection 
of  effective  decision  aids  for  TCO. 

As  a  by-product  of  this  effort,  a  methodology  for  assessment  of  the 
importance  of  TCO  capabilities  with  respect  to  function  performance  was 
established.  This  methodology  is  also  documented  in  the  present  report. 

It  is  based  on  a  taxonomy  of  behaviors  and  provides  a  framework,  similar 
to  the  matching  principles  developed  during  the  first-year  program,  for 
relating  the  required  behaviors  to  the  behaviors  enhanced  by  each  TCO 
capability.  The  application  of  this  framework  yields  a  score  which 
depicts  the  degree  of  effectiveness  of  a  given  TCO  capability  for  a 
specific  function. 
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This  appendix  Is  Intended  to  be  presentable  as  a  stand-alone  document. 
Also  Included  Is  an  analysis  of  TCO  functions.  In  Section  A. 2,  as  well  as 
an  analysis  of  TCO  capabilities  In  Section  A. 3.  Section  A. 4  presents  the 
decision  aid  selection  process  and  the  associated  results. 


A. 2  TCO  DECISION  TASK  FUNCTIONAL  ANALYSIS 


A. 2.1  TCO  functional  Analysis 

A. 2. 1.1  TCO  Functional  Decomposition.  As  part  of  the  on-going  TCO  develop¬ 
ment  effort,  an  analysis  of  the  military  functions  to  be  supported  by  TCO 
has  been  performed  by  the  Marine  Corps  Tactical  System  Support  Activity. 

The  results  of  this  study  are  documented  in  the  preliminary  System 
Description  Document  (PSDD),  which  contains,  in  particular,  a  hierarchical 
decomposition  of  TCO  functions.  The  TCO  decomposition  yields  a  logic 
tree  depicted  in  Figure  A-l,  which  portrays  system  requirements  (also 
referred  to  as  functional  elements)  as  leaves  of  the  tree.  The  level  of 
detail  thus  reached  was  sufficient  to  permit  the  definition  of  92  system 
capabilities  that  altogether  constitute  the  TCO  concept. 

The  first-year  effort  provided  an  analysis  based  upon  Marine  Corps  doc¬ 
trine  and  encompassed  the  entire  spectrum  of  Marine  Amphibious  Brigade 
operations.  This  part  of  the  second-year  effort,  documented  In  this 
appendix,  applies  the  methodology  developed  during  the  first  year  to  the 
selection  of  a  decision  aid  for  inclusion  in  the  TCO  concept.  Consequently, 
it  was  appropriate  to  use,  as  a  basis,  the  TCO  functional  decomposition 
developed  by  the  TCO  project  team  described  above. 

A. 2. 1.2  TCO  Decision-Task  Identification.  The  decision-task  analysis 
performed  during  the  first  year  program  was  brought  to  bear  on  the  TCO 
functional  decomposition.  This  allowed  identification  of  those  bottom- 
level  TCO  functions  that  are  decision  tasks.  Validation  of  the  results 
of  the  identification  process  was  sought  through  structured  interview 
of  Marine  Corps  personnel  at  MCTSSA.  Subjects  were  requested  to  focus 
on  the  leaves  of  the  logic  tree  depicting  TCO  functions  (Figure  A-l)  and 
Identify  among  them  those  that  involve  significant  decisions.  The  results 
obtained  through  the  interview  were  identical  to  those  derived  from 
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TCO  FUNCTIONAL  DECOMPOSITION:  OPERATIONS 
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FIGURE  A-lc. 

TCO  FUNCTIONAL  DECOMPOSITION:  INTELLIGENCE 
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the  methodology  established  during  the  first  year.  These  results  are 
depicted  in  Figure  A-l  where  decision  tasks  are  singled  out  with  ' D.T. ' 
in  the  upper  right  corner  of  the  corresponding  box. 

A. 2. 1.3  TCP  Functional  Weight  Assessment.  In  order  to  assess  the  relative 
Importance  of  the  TCO  bottom-level  functions,  i.e.,  the  leaves  of  the 
logic  tree,  a  top-down  procedure  based  upon  importance  weights  elicited 
from  experts  was  applied.  It  consists  of  eliciting  branch  weights, 
normalizing  them  and  rolling  them  back  to  the  top  of  the  tree.  To  illus¬ 
trate  the  procedure  assume  that  an  expert  assessed  the  relative  Importance 
of  Operations  in  Marine  Corps  missions  as  .750  and  that  of  Control  Ground 
Maneuver  in  Operations  as  .400.  Assume  further  that  the  subject's  estimate 
of  the  relative  importance  of  Conduct  Immediate  Ground  Planning  for  Control 
of  Ground  Maneuver  is  .300.  The  overall  importance  of  Conduct  Immediate 
Ground  Planning  for  the  mission  will  be  .750  x  .400  x  .300  *  .090. 

Applying  systematically  this  procedure  yields  an  importance  weight  w^  for 
each  functional  element  (leaf  of  the  tree)  and  consequently  for  each 
decision  task.  Note  that  the  total  sum  of  weights  over  all  functional 
elements  Is  equal  to  one,  but  that  the  sum  of  weights  over  decision  tasks 
is  less  than  one. 

In  order  to  assess  the  relative  importance  of  TCO-supported  functions  for 
Marine  Corps  missions,  branch  weights  were  elicited.  The  SMART  elicitation 
method  (Edwards,  1971)  was  selected  due  to  its  main  advantages,  which  are: 
(1)  It  is  simple  and  can  easily  be  taught,  and  (2)  It  does  not  require 
judgments  of  preference  among  hypothetical  entities.  The  method  roughly 
consists  of  the  following  steps:  (1)  rank  entities  in  order  of  importance, 
and  (2)  rate  the  entities  in  Importance  while  preserving  ratios,  namely: 
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(1)  Assign  10  to  the  least  important  item. 

(2)  Consider  next-least  important  item  and  assess  how  much 
more  important  it  is  than  the  least  important  by  assigning 
a  number  reflecting  the  ratio. 

(3)  Continue  with  next  item  while  checking  for  consistency. 

The  steps  above  were  followed  during  the  interview  of  four  Marine  Corps 
personnel  based  at  MCTSSA  who  served  as  subject  matter  experts.  Two 
interviewees  had  a  ground  operations  background,  one  had  an  aviation 
operations  background,  and  one  had  an  extensive  intelligence  background. 
The  interviewees'  assessments  showed  a  high  degree  of  concordance.  Conse¬ 
quently,  the  final  weight  was  taken  as  the  simple  average  of  the  four 
weights.  The  results  are  portrayed  in  Figure  A-2.  A  striking  fact  is  the 
apparent  imbalance  of  the  three  major  functions  supported  by  TCO,  since 
Operations  account  for  67%  of  the  total  while  Intelligence  and  Planning 
respectively  account  for  25%  and  8%  of  the  total.  In  addition  to  the 
general  results  of  Figure  A-2,  the  highly  weighted  decision  tasks  are 
portrayed  in  Table  A-i.  All  high-weight  decision  tasks  belong  to  the 
functional  areas  Operations  or  Intelligence.  The  decision  task  with  the 
highest  weight  in  Planning  is  'Develop  Courses  of  Action'  with  a  weight 
of  .016. 


A. 2. 2  TCO  Function  Classification 


| 

1 

t 


A. 2. 2.1  Behavioral  Function  Classification.  As  mentioned  earlier,  TCO 
functional  decomposition  was  carried  out  until  a  level  of  detail  sufficient 
for  definition  of  system  capabilities  was  reached.  A  matrix  of  TCO  func¬ 
tions  by  TCO  capabilities  was  established  and  Included  in  Appendix  F  of 
the  TCO  PSDD.  This  matrix  portrays  the  function/ capability  binary  relation¬ 
ships,  i.e.,  allows  Identification  of  the  capabilities  required  for  perfor¬ 
mance  of  a  given  function. 
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TABLE  A-l 

HIGHLY  WEIGHTED  DECISION  TASKS 


Modify  Air  Support  Schedule  .097 
Correlate  Incoming  Information  .051 
Modify  Target  List  .048 
Prepare  Ground  Reports,  Requests,  and  Orders  .036 
Insert,  Modify,  Delete  Control  Measures  .032 
Conduct  Immediate  Ground  Planning  .031 
Analyze  Incoming  Information 


.031 


The  TCO  project  team  identified  a  requirement  to  validate  this  matrix  or 
find  a  methodology  to  accommodate  non-binarv  relations,  i.e.,  to  construct 
a  "function  x  capability"  matrix  whose  entries  would  be  numbers  between 
0  and  1  measuring  "how  much"  of  a  given  capability  is  required  for  perfor¬ 
mance  of  a  given  function.  As  a  by-product  of  the  present  effort,  a 
methodology  to  fulfill  this  requirement  was  developed  and  is  described  in 
the  following. 

The  first  step  of  the  methodology  is  to  develop  a  taxonomy  of  human 
behaviors,  i.e.,  a  set  that  contains  all  possible  behaviors  that  could  be 
encountered  in  analyzing  tasks  and  such  that  the  behavioral  categories 
defined  do  not  overlap.  Thus,  any  task  can  be  represented  as  a  binary 
vector,  with  one  meaning  that  the  corresponding  behavior  is  required  for 
task  performance,  and  zero  that  it  is  not.  Another  alternative  would  be 
to  represent  each  task  as  a  vector  of  numbers  between  0  and  1,  each  entry 
measuring  how  important  the  corresponding  behavior  is  for  task  performance. 
Whatever  the  solution  retained,  a  task  can  be  symbolically  represented  as 
a  vector: 

t  *  (tj»  ...,  f | g | ) 

where  the  entries  are  numbers  between  0  and  1  as  explained  above. 

The  taxonomy  of  behaviors  suggested  in  this  particular  case,  is  that  of 
Berliner,  et  al.  (1964),  which  is  well-known  and  general  considered 
"reasonably  descriptive  of  behaviors  that  can  be  observed  in  task  perfor¬ 
mance"  (Meister,  1976).  This  taxonoiqy  is  presented  in  Table  A-2. 

A. 2. 2. 2  Decision  Task  Classification.  In  the  previous  paragraph,  the 
Importance  of  having  at  one's  disposal  a  taxonomy  of  behaviors  was  stressed 
since  tasks  can  be  classified  according  to  the  categories  contained  in 


TABLE  A- 2 

TAXONOMY  OF  BEHAVIORS  (BERLINER  ET  AL.  1964) 


PROCESSES 


1.  PERCEPTUAL 
PROCESSES 


2.  MED I AT I ON AL 
PROCESSES 


3.  COMMUNICATION 
PROCESSES 


4.  MOTOR  PROCESSES 


ACTIVITIES 

BEHAVIORS 

1.1 

Searching  for  and 

Receiving  Information 

Detects 

Inspects 

Observes 

Reads 

Receives 

Scans 

Surveys 

1.2 

Identifying  Objects, 
Actions,  Events 

Discriminates 
Identi fles 
Locates 

2.1 

Information  Processing 

Categorizes 

Calculates 

Codes 

Computes 

Interpolates 

Itemizes 

Tabulates 

Translates 

2.2 

Problem  Solving  and 

Decision  Making 

Analyzes 

Calculates 

Chooses 

Compares 

Computes 

Estimates 

Plans 

Advises 

Answers 

C  annum' cates 
Directs 

Indicates  1 

Informs 

Instructs 

Requests 

Transmits 

4.1 

Simple/Discrete 

Activates 

Closes 

Connects 

Disconnects 

Joins 

Moves 

Presses 

Sets 

Adjusts 

Aligns 

Regulates 

Synchronizes 

Tracks 

4,2 

Comp 1 ex /Conti nuous 

the  taxonomy.  The  level  of  detail  that  is  retained  in  the  taxonomy  depends 
upon  the  purpose  of  the  analysis.  For  the  purpose  of  ranking  TCO  capabili¬ 
ties,  one  could  use  only  activities  (see  Table  A-2).  This  was  actually 
done  and  the  results  of  the  analysis  of  TCO  functional  elements  in  terms 
of  activities  are  depicted  in  Appendix  B. 

For  selecting  a  decision  aid,  it  is  clear  that  using  the  taxonomy  of 
Berliner,  et  al.  at  the  level  of  activities  would  not  be  sati factory 
since  no  discrimination  power  would  be  provided.  Consequently,  the  taxonomy 
of  decision-making  behaviors  (also  called  functional  requirements)  developed 
during  the  first  year  program  was  utilized.  Those  functional  elements 
identified  as  decision  tasks  were  classified  in  terms  of  their  functional 
requirements,  as  well  as  their  attributes.  The  results,  which  are  depicted 
in  Appendix  B,  served  as  a  basis  for  application  of  the  matching  principles 
developed  during  the  first  year  program  that  produces  a  degree  of  merit 
for  each  decision-aiding  technique  with  respect  to  a  given  decision  situation. 


A. 3  TCO  CAPABILITY  ANALYSIS 


A. 3.1  TCO  Capabilities  and  Human  Activities 

TCO  is  described  at  length  in  the  PSDD,  and  TCO  capability  definitions  can 
be  found  in  an  unpublished  document  called  "TCO  Capabilities  Identification," 
prepared  for  TCO  test  02-79  run  at  MCTSSA.  These  definitions  have  been 
reproduced  in  "Final  MTF  TCO  Functional  Requirements  Document,"  27  February 
1980,  prepared  by  the  Planning  Research  Corporation.  TCO  capability 
definitions  have  been  reproduced  in  Appendix  C. 

In  general,  a  capability  is  aimed  at  certain  activities  (according  to  the 
taxonomy  of  activities  portrayed  in  Table  A-2),  i.e.,  it  is  designed  to 
aid  or  facilitate  certain  types  of  human  activities.  Using  the  definitions, 
all  TCO  capabilities  were  classified  according  to  the  activities  they  aim 
at.  The  results  of  this  analysis  are  portrayed  in  Table  A-3.  The  capa¬ 
bilities  for  which  N/A  (non-applicable)  appears  are  actually  requirements 
in  which  TCO  operators  do  not  play  any  role;  and  consequently  these 
capabilities  do  not  lend  themselves  to  the  proposed  analysis. 

Each  TCO  capability,  therefore,  (just  as  any  TCO  functional  element)  can 
now  be  represented  as  a  binary  vector,  with  one  meaning  that  the  correspond¬ 
ing  activity  is  present  and  a  zero  meaning  that  it  is  absent.  Again,  the 
numbers  need  not  be  zero  or  one.  It  is  theoretically  possible  to  define 
a  number  representing  the  degree  of  facilitation  provided  by  a  TCO  cap¬ 
ability  in  the  performance  of  an  activity.  Hence,  a  capability  can  be 
represented  as  a  vector 

£  *  (Cj »  • • »  C.B|) 

similarly  to  the  representation  of  t. 


TABLE  A-3 


CLASSIFICATION  OF  TCO  CAPABILITIES  BY  ACTIVITIES  SUPPORTED 

CAPABILITY 

1*  Enter  Graphics  Manually  on  Line 

2.  Exchange  Track  Data  Automatically 

3.  Enter  Text  Automatically 

а.  Enter  Data  Via  Machine  Readable  Medium 

5.  Enter  Text  Manually  on  Line 

б,  Store  Graphics  Information  In  Data  Base 

7.  Process  Text  in  Planning  Framework 
3.  Store  Text  in  Journal 

9.  Store  Message  Header  Incoming  Message  Queue 

10.  Store  Text  in  Data  Base 

11.  Process  Text/Graphics  Via  Remote  Terminal 

12.  Hook  to  Amplify  Graphic  Display 

13.  Inter  System  Graphic  Queries 

14.  Reauest  Graphics  oy  Plain  Language  Query 

15.  Request  Graphics  by  Intrasystem  Query 

16.  Request  Graphics  by  SRI 

17.  Select  Graohics  from  Prompt  List 

18.  Hook  to  *nplify  Text  Display 

19.  Intersystem  Text  Queries 

20.  Request  Text  by  Plain  language  Query 

21.  Intrasystem  Text  Queries 


22.  Request  Text  by  Standing  Request  *or  Information  3. 

23.  Select  Text  from  Prompt  List  1.1. 

2*.  Select  Preformatted  Display  3. 

25.  Print  Graphics  by  Operator  Action  3. 

26.  Print  Text  Automatically  Upon  Receipt  3. 

27.  Print  Text  by  Operator  Action  3. 

28.  Display  Grapnics  Automatically  Upon  Receipt  1.1. 

29.  Process  Graphics  1r,  Scratch  Pad  2.1. 

20.  Map  Oisplay  Control  3, 

31.  Highlight  Graphics  2,1. 

32.  Graphic  Selective  Erase  2.1. 

33.  Smooth  Graphic  Symbols  2.1. 

34.  Annotate  Source  of  Symbols  3. 

35.  Time  Tag  Information  3, 

36.  Distinguish  Friend/Enemy  Unit  3. 

37.  Distinguish  Proctssed/Unorocessed  Intelligence  3. 

38.  Control/Oisplay  Pointer  2.1. 

39.  Construct  and  Process  Symbols  2.1. 

40.  Close  Control  Graphics  1.2.  2.1. 

41.  Display  Text  Automatically  Uoon  Rectiot  l.l 

42.  Display  Text  by  Operator  Action  3, 

43.  Process  Text  in  Scratch  Pad  2.1. 

44.  Scroll/Page  Text  2.1 

45.  Close  Control  Text  1.2.  2.1, 

46.  Intra  Center  Dissemination  of  Text/Graohtcs  3. 
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CORRESPONDING 

ACTIVITIES 

2.1.  3. 

M/A 

2.1.  3. 

3. 

2.1.  3. 
3. 

1.1  2.1 

1.1. 

1.1. 

3. 

2.1. 

1.2. 

N/A 

3. 

N/A 

3. 

1.1. 

1.2. 

M/A 

3. 

N/A 


TABLE  A-3  (CONTINUED) 


CAPABILITY 

47.  Display  in  Conference  Moce 

•18.  Intra  System  Dissemination  of  Text/Graphics 

49.  Inter  System  Dissemination  of  Text/Graphics 

50.  High  Precedence  Message  Alert 

51.  Call  Sack  Upon  Receipt  of  Requested  Data  Alert 

52.  Local  Parameters  Alert 

53.  Task  Identification/Scroll  Queue 

54.  Run  Combat  Simulation 

55.  Run  Simulation  by  Snapshots 

56.  Enter/Oelete  A/C  Sort  Rate  Parameter 

57.  Enter/Oelete  Mission  Requirements  Parameter 

58.  Enter/Delete  A/C  Locations  Parameter 

59.  Enter/Delete  A/C  Character  Parameter 

60.  Enter/Oelete  Unit  Movement  Parameter 

61.  Calculate  Combat  Power  Ratio 

62.  Calculate  Time/Distance  Ratio 

63.  Calculate  Fuel  Consumption 

64.  Calculate  Casualty  Estimates 

65.  Calculate  A/C  to  Mission  Assignment 

66.  Calculate  Ordnance  for  Target/Mission 

67.  Calculate/Olsplay  Sensor  Placement  and  Coverage 


68.  Calculate/Oisplay  Minefield  Coverage  2.2. 

69.  Perform  Track  Management  2.1. 

70.  Automatic  Generation  of  Tables  2.1. 

71.  Perform  Reasonableness  Checks  2.2. 

72.  Operate  in  Local  Mode  N/A 

73.  Interface  PLRS  M/A 

74.  Interface  MIFASS  N/A 

75.  Interface  TAOC-85  N/A 

76.  Interface  MIPS  N/A 

77.  Interface  MILOGS  N/A 

78.  Interface  MAGIS  N/A 

79.  Interface  External  System  N/A 

30.  Operate  with  Portion  Data  Base  N/A 

31.  Operate  with  Portion  Equipment  Suite  N/A 

32.  Load/Reload  from  Auxiliary  Memory  N/A 

33.  Decentralization  of  Operator  Functions  N/A 

34.  Assumption  of  Additional  Processing  Functions  N/A 

35.  Shift  TCO  Functions  to  MIFASS  N/A 

36.  Word  Processing  2.1. 

37.  Display  Information  For  Group  Viewing  3. 

38.  Process  Graphics  Off  Line  2.1. 

39.  Select/Store  Named  Display  2.1. 

90.  Oelete  Text/Graphics  3. 

91.  Calculate  Lint  of  Sight  2.2. 

92.  Calculate  Materiel  Retirements  2.2. 


CORRESPONDING 

ACTIVITIES 

3. 

3. 

N/A 

1.1.  1.2. 

1.1. 

•  ^ 

1.1. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 

2.2. 


For  each  functional  element  t  *  (tj,  ...  t  g  )  and  each  capability  c 
...  C|g[)  a  degree  of  matching  d  can  be  computed  as 


where 

ab  *  max  (o,  tb  -  cb) 

d  is  a  quantity  between  0  and  1  that  represents  how  well  a  given  TCO  cap¬ 
ability  fulfills  the  activity  requirements  of  a  given  functional  element. 
Consider  functional  element,  "Monitor  A/C  Tactical  Air  Requests,"  which 
can  be  represented  as  (1  1  0  0  0  0  0)  since  it  requires  activities  1.1  and 
1.2.  Now  consider  TCO  capability  #40  Close  Control  Graphics.  It  can  be 
represented  as  (0  1  1  0  0  0  0)  thus  implying  d  *  1/2.  Similarly, 
capability  #50  High  Precedence  Message  Alert  can  be  represented  as 
(1  1  0  0  0  0  0)  thus  Implying  d  «  1  for  the  same  functional  element. 

Consequently,  the  function  x  capability  matrix  can  be  filled  with  numbers 
between  0  and  1,  each  entry  representing  how  well  the  corresponding  cap¬ 
ability  fits  the  corresponding  functional  element.  It  can  of  course  be 
expected  that  the  finer  the  taxonomy  used,  the  more  heterogeneous  the 
numbers  will  be,  thus  allowing  fine-grained  discrimination  between  capa¬ 
bilities  for  a  given  functional  element. 

A. 3. 2  TCO  Capabilities  and  Decision  Aids 


Since  It  Is  required  to  select  a  decision  aid  for  TCO,  It  Is  very  Important 
to  Identify  those  TCO  capabilities  that  are  In  fact  decision  aids.  This 


will  avoid  duplication  of  developmental  efforts;  at  the  same  time,  a  figure 
of  merit  for  TCO  decision  aids  will  be  obtained.  Thus  if  trade-off 
analyses  are  conducted  to  cut  costs  by  suppression  of  capabilities,  a 
basis  will  be  available. 

Preliminary  analysis  of  TCO  capabilities  revealed  that  they  actually  fall 
into  three  categories: 

(a)  Capabilities  that  are  unrelated  to  decision  making  (e.g., 
straight  input/output  operations). 

(b)  Capabilities  that  enhance  decision  making  to  some  extent 
(e.g.,  by  providing  a  graphic  display  of  relevant  information) 

(c)  Decision  aids  per  se. 

TCO  capabilities  were  consequently  screened  and  classified  as  belonging 
to  categories  a,  b,  or  c.  The  decision-aiding  technique  used  was  identi¬ 
fied  by  using  the  taxonoiqy  of  decision-aiding  techniques  developed  during 
the  first-year  effort.  The  results,  which  are  depicted  in  Table  A-4, 
show  that  the  following  decision-aiding  techniques  are  already  used  to  at 
least  some  extent  in  the  TCO  concept:  Warfare  Area  Models,  Scheduling, 
Mathematical  Programming,  Tactical  Simulation,  Man-Machine  Communication, 
Coverage  Templates,  Time/Distance  Algorithms,  and  Message  Processing. 


TABLE  A-4 

CLASSIFICATION  OF  TCO  CAPABILITIES  BY  TECHNIQUE  EMPLOYED 


CAPABILITY 

CLASSIFICATION 

TECHNIQUE 

1. 

Enter  Graphics  Manually  on  Line 

a 

- 

2. 

Exchange  Track  Data  Automatically 

N/A 

■ 

3. 

Enter  Text  Automatically 

a 

4. 

Enter  Data  Via  Machine  Readable  Medium 

a 

5. 

Enter  Text  Manually  on  Line 

a 

6. 

Store  Graphics  Information  in  Data  Base 

a 

7. 

Process  Text  in  Planning  Framework 

a 

8. 

Store  Text  in  Journal 

a 

9. 

Store  Message  Header  Incoming  Message  Queue 

b 

Message  Processing 

10. 

Store  Text  in  Data  3ase 

a 

- 

11. 

Process  Text/Grapnics  Via  Remote  Terminal 

b 

Man-Machl ne 
Communication 

12. 

Hook  to  Amplify  Graphic  01  splay 

b 

Man-Machine 

Communication 

13. 

Inter  System  Graphic  Queries 

N/A 

- 

14. 

Request  Graphics  by  Plain  Language  Query 

b 

MMC 

15. 

Request  Graphics  by  Intrasystem  Query 

N/A 

- 

16. 

Request  Grapnics  by  SRI 

b 

MP 

17. 

Select  Graohics  from  Prompt  List 

b 

MMC 

18. 

Hook  to  Amplify  Text  Display 

b 

me 

19. 

Intersystem  Text  Queries 

N/A 

- 

20. 

Request  Text  by  Plain  Language  Query 

b 

me 

21. 

Intrasystem  Text  Queries 

N/A 

- 

22. 

Request  Text  by  Standing  Request  for  Information 

b 

MMC 

23. 

Select  Text  from  Prompt  List 

b 

me 

24. 

Select  Preformatteo  Display 

b 

me 

25. 

Print  Graphics  by  Ooerator  Action 

a 

- 

26. 

Print  Text  Automatically  Upon  Receipt 

a 

- 

27. 

Print  Text  by  Operator  Action 

a 

- 

28. 

Qisplay  Graphics  Automatically  Upon  Receipt 

a 

- 

29. 

Process  Graphics  in  Scratch  Pad 

a 

- 

30. 

Map  Display  Control 

b 

MMC 

31. 

Highlight  Graphics 

b 

MMC 

32. 

Graphic  Selective  Erase 

b 

me 

33. 

Smooth  Graphic  Symbols 

b 

me 

34. 

Annotate  Source  of  Symbols 

b 

MMC 

35. 

Time  Tag  Information 

b 

MMC 

36. 

Distinguish  Friend/Enemy  Unit 

b 

me 

37. 

Distinguish  Processed/Unprocessed  Intelligence 

a 

38. 

Control /Display  Pointer 

a 

39. 

Construct  and  Process  Symbols 

a 

40. 

Close  Control  Graphics 

a 

41. 

Display  Text  Automatically  Upon  Receipt 

a 

42. 

Display  Text  by  Operator  Action 

a 

43. 

Process  Text  in  Scratch  Pad 

a 

44. 

Scroll /Page  Text 

a 

45. 

Close  Control  Text 

a 

46. 

Intra  Center  01 sseml nation  of  Text/Graphics 

a 

47. 

Display  in  Conference  Mode 

b 

me 

48. 

Intra  System  Dissemination  of  Text/Graph1cs 

b 

me 

TABLE  A- 4  (CONTINUED) 


CAPABILITY 

CLASSIFICATION 

TECHNIQUE 

49. 

Inter  System  Dissemination  of  Text/Graphics 

N/A 

- 

50. 

High  Precedence  Message  Alert 

b 

MP 

51. 

Call  Back  Upon  Receipt  of  Requested  Data  Alert 

b 

MP 

52. 

Local  Parameters  Alert 

b 

MMC 

53. 

Task  Identification/Scroll  Queue 

a 

- 

54. 

Run  Combat  Simulation 

c 

Tactical  Simulation 

55. 

Run  Simulation  by  Snapshots 

c 

Tactical  Simulation 

56. 

Enter/Delete  A/C  Sort  Rate  Parameter 

a 

57. 

Enter/Delete  Mission  Requirements  Parameter 

a 

58. 

Enter/Oelete  A/C  Locations  Parameter 

a 

59. 

Enter/Oelete  A/C  Character  Parameter 

a 

60. 

Enter/Delete  Unit  Movement  Parameter 

a 

61. 

Calculate  Combat  Power  Ratio 

c 

Warfare  Area 
Models 

62. 

Calculate  Time/Oistance  Ratio 

c 

Time/Distance 
Algori thms 

63. 

Calculate  Fuel  Consumption 

c 

Time/ Distance 
Algorithms 

64. 

Calculate  Casualty  Estimates 

c 

Time/Distance 
Algori  thms 

65. 

Calculate  A/C  to  Mission  Assignment 

c 

Scheduling/Mathe- 
matlcal  Programming 

56. 

Calculate  Ordnance  for  Target/Mission 

c 

Mathematical  Pro¬ 
gramming 

67. 

Calculate/Oisplay  Sensor  Placement  and  Coverage 

c 

Mathematical  Pro¬ 
gram^  ng/Coverage 
Template 

68. 

Calculate/Di  splay  Minefield  Coverage 

c 

Problem  Solving/ 
Coverage  Template 

59. 

3erform  Track  Management 

b 

MNC 

70. 

Automatic  Generation  of  Tables 

b 

T1 me/01 stance 
Algori  thms 

71. 

Perform  Reasonableness  Checks 

c 

MMC 

72. 

Operate  in  Local  Mode 

N/A 

73. 

Interface  PLRS 

N/A 

74. 

Interface  MIFASS 

N/A 

75. 

Interface  TAGC-85 

N/A 

76. 

Interface  MIPS 

N/A 

77. 

Interface  MILOGS 

N/A 

78. 

Interface  MAGIS 

N/A 

79. 

Interface  External  System 

N/A 

80. 

Operate  with  Portion  Oata  Base 

N/A 

81. 

Operate  with  Portion  Equipment  Suite 

N/A 

82. 

Load/Reload  from  Auxiliary  Memory 

N/A 

83. 

Decentralization  of  Operator  Functions 

N/A 

84. 

Assumption  of  Additional  Processing  Functions 

N/A 

35. 

Shift  TCO  Functions  to  MIFASS 

N/A 

86. 

Word  Processing 

a 

87. 

Display  Information  for  Group  Viewing 

b 

me 

38. 

Process  Graphics  Off  Line 

a 

39. 

Select/Store  Mamed  Display 

a 

90. 

Oelete  Text/Graphics 

a 

91. 

Calculate  Line  of  Sight 

c 

Time/Distance 

Algorithms 

32. 

Calculate  Materiel  Requirements 

c 

Time/ Distance 

A1  gorl  thms 

f 


A. 4  DECISION  AID  SELECTION 
A. 4.1  Decision  Aid  Ranking 

Using  the  matching  principles  set  forth  during  the  first-year  program,  it 
is  now  possible  to  define  a  degree  of  merit  (called  aiding  score)  for 
every  decision-aiding  technique  with  respect  to  every  TCO  decision  task. 
Let  this  aiding  score  be  s^,  where  i  stands  for  the  decision  task  and  j 
for  the  decision-aiding  technique.  In  order  to  obtain  an  overall  assess¬ 
ment  of  the  potential  benefit  of  each  decision-aiding  technique  for  TCO- 
supported  decision  tasks,  it  is  required  to  summarize  these  aiding  scores 
into  a  single  figure  of  merit.  An  obvious  solution  is  to  compute  an 
average  aiding  score,  the  average  being  taken  over  all  TCO-supported 
decision  tasks.  All  decision  tasks,  however,  are  not  equally  important 
as  demonstrated  by  TCO  functional  analysis  that  yielded  an  importance 
weight  for  each  functional  element,  hence  for  each  decision  task.  Conse¬ 
quently,  we  can  calculate 


Sj  ~  ^  wi  sij 

i  TCO 
decision 
task 


where  w^  is  the  importance  weight  of  decision  task  i.  Note  that  the  w^'s 
are  not  normalized,  i.e.,  the  sum  of  w^ 's  over  decision  tasks  is  strictly 
lower  than  one.  However,  this  is  of  not  consequence  since  it  is  only 
required  to  rank  decision-aiding  techniques.  In  other  words,  the  S^'s 
are  used  for  the  purpose  of  comparison  only  and  not  as  absolute  numbers. 

The  calculations  required,  although  simple,  were  In  overwhelmingly  large 
numbers  so  that  a  program  was  written  to  automatically  compute  the  S,'s. 

J 
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Inputs  to  the  program  were  TCO-supported  decision  task  descriptions  in 
terms  of  the  attributes  and  functional  requirements  as  depicted  in  Appendix 
A.  Also,  inputs  to  the  program  were  the  aiding  technique  x  functional 
requirement  and  aiding  technique  x  decision- task  attribute  relevance 
matrices  (Figures  5-2  and  5-3  of  first  year  final  report).  The  results 
are  depicted  in  Table  A-5.  Note  that  the  highest  score  is  that  of  Tact¬ 
ical  Simulation,  which  is  already  included  in  the  TCO  concept.  Similarly, 
Man-Machine  Communication,  which  is  to  a  large  extent  already  included  in 
the  TCO  concept,  also  receives  a  very  high  score.  The  analysis  therefore 
supports  the  early  decision  of  TCO  concept  designers  to  include  these 
techniques. 

A. 4. 2  Decision  Aid  Selection 

The  average  aiding  scores  were  of  course  used  as  a  basis  for  selection  of 
a  decision-aiding  technique  for  inclusion  in  the  TCO  concept.  However, 
other  considerations  preside  over  this  selection.  A  working  session  was 
therefore  organized  at  MCTSSA  in  order  to  select  an  effective  decision- 
aiding  technique  within  the  constraints  imposed  by  the  project  and  satisfy¬ 
ing  user's  desiderata. 

Table  A-6  presents  thirteen  decision-aiding  techniques  which  are  a  priori 
candidates  due  to  their  high  score.  First,  it  was  noted  that  three  of 
these  techniques  were  already  included  in  the  TCO  concept  and  were  thus 
disqualified  on  the  basis  of  non-duplication  of  efforts.  Another  five 
techniques  were  readily  transferable  and  thus  rejected  since  the  program 
affords  a  unique  opportunity  to  develop  available  techniques  for  a  new 
concern  (Partial  Information  Based  Decision  Analysis  was  developed  by 
Perceptronl cs  under  a  DARPA  program  while  the  four  other  decision-aiding 
techniques  are  part  of  Perceptronl cs'  Group  Decision  Aid,  which  Is  a 
stand-alone,  portable  device).  Finally,  another  two  techniques  required 


TABLE  A- 5 


AVERAGE  DECISION-AIDING  TECHNIQUE  AIDING  SCORES 
FOR  TCO- SUPPORTED  DECISION  TASKS 


'ACT  I cal  s  inflation 

.2*6 

PROBLEM  SOLVING 

3*« 

OCCISION  TREE  structuring 

.344 

DATABASE  SAGANIIATION 

.341 

GROUP  OECISICN  ANALYSIS 

.337 

,  PATTERN-0 IRECTED  INFERENCE  SYSTEMS 

.330 

t  NAN-MACHINE  COPRRJNICATION 

.324 

j  INFORMATION  ANO  DISCRIMINATION  MEASURES 

.333  | 

I  PLANNING  '•COON ISMS 

CLASSIFICATION 

.305  j 

PARTIAL  INFORMATION  BASED  OECISIU*  ANALYSIS 

.295  f 

tuc^i -attribute  CTIl:4^  ANALYSIS 

.291  i 

SUBJECTIVE  EXPECTED  UTILITY 

.239 

FUZZY  Decision  ANALYSIS 

.230 

4ARFARC  AREA  NOOElS 

.2T*  | 

ICVERAGE  'EMPUTES 

.271  | 

LINEAR  DISCRIMINANT  FUNCTIONS 

.270  | 

lanckester'S  theory  :f  cowat 

.267  | 

i  cost-benefit  analysis 

.253  ; 

j  RISK-BENEFIT  ANALYSIS 

rsi 

;  DISCOUNTING  NOOELS 

.245  | 

|  PROBA  ’NJLTI -ATTRIBUTE  UTILITY  ANALYSIS 

.239  I 

SAMI  'MEQRY 

.239  , 

SIMULATION  ANO  4lft  GAMING 

'inn 

GROUP  UTILITY  AGGREGATION 

.205 

1  SCHEDULING 

.19*  j 

UTILITY  ASSESSMENT  TECHNIQUES 

.193  j 

CLUSTERING 

.133 

TIME/OISTANCE  ALGORITHMS 

.173 

MATHEMATICAL  PROGRAMING 

:  .152  ! 

MESSAGE  PROCESSING 

;  BAYESIAN  UPDATING 

.137  | 

i  SIGNAL  DETECTION 

.133  | 

GROUP  PROBABILITY  AGGREGATION 

L«l1 

*CNT!  CARLO  NCTHOOS 

sa 

PROBLEM  REPRESENTATION 

ma\ 

sensitivity  analysis 

.399  1 

TIME  INVARIANT  STATISTICAL  DETECTION 

.392  j 

search  modeling 

.381  i 

*  PROBABILITY  elicitation  ; 

.079  i 

(  LEARNING  SYSTEMS  J 

3 
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TABLE  A- 6 


HIGH-SCORED  DECISION  AIDING  TECHNIQUES 


Tactical  Simulation  .376 
Problem  Solving  .346 
Decision  Tree  Structuring  .344 
Man-Machine  Communication  .342 
Database  Organization  .341 
Group  Decision  Analysis  .337 
Pattern-Directed  Inference  Systems  .330 
Information  and  Discrimination  Measures  .323 
Planning  Mechanisms  .322 
Classification  .305 
Partial  Information  Based  Decision  Analysis  .295 
Multi-Attribute  Utility  Analysis  .291 
Subjective  Expected  Utility  .289 


Already  Included  in  TCO 
Readily  Available  for  Transfer 
Requires  Long-Term  Effort 
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a  very  long  term  effort  due  to  their  present  stage  of  development  and 
were  therefore  rejected  as  beyond  the  scope  of  the  project. 


Three  decision-aiding  techniques  were  left  for  discussion.  They  are 
portrayed,  together  with  their  aiding  scores  with  respect  to  TCO-supported 
decision  tasks,  in  Table  A-7.  Simultaneous  inspection  of  the  figures 
portrayed  in  Table  A-7  and  the  decision-task  weights  led  to  the  selection 
of  a  few  good  matches  between  selected  decision-aiding  techniques  and 
particularly  important  TCO-supported  decision  tasks.  This  table  of 
correspondance  depicted  in  Table  A-8  was  used  as  a  basis  for  the  last 
phase  of  the  decision-aid  selection  process. 

First  it  was  noted  that  problem-solving  techniques  mainly  apply  to  tasks 
that  are  currently  studied  under  the  auspices  of  another  program  and 
were  consequently  not  selected.  MCTSSA  personnel  emphasized  their  interest 
in  Combat  Information  Correlation.  Since  Classification  matches  this  task 
well,  it  was  decided  to  select  it  as  a  decision-aiding  technique  and  to 
initiate  development  for  Information  Correlation.  In  addition,  a  subtask 
of  Information  Correlation,  which  is  the  management  of  information  gather¬ 
ing  sources,  lends  itself  to  Information  and  Discrimination  Measures  as 
a  decision-aiding  technique.  Consequently,  the  development  of  Classi¬ 
fication  (primarily)  and  Information  and  Discrimination  Measures  (second¬ 
arily)  was  initiated  for  Combat  Information  Correlation.  Examination  of 
the  task  attributes  revealed,  through  use  of  the  decision- task  attribute  x 
decision-aid  feature  relevance  matrix  (Figure  5-4  of  the  first-year  final 
report)  that  the  required  decision-aid  features  are: 

.  flexible 
.  interactive 
.  real  time 

These  requirements  provide  guidelines  for  maximum  implementation  efficiency. 


A- 24 


TABLE  A- 7 

INDIVIDUAL  AIDING  SCORES  FOR  SELECTED 
DECISION-AIDING  TECHNIQUES 


Establish  Collection  Requirements 

Develop  Collection  Plan 

Reauest  Combat  Readiness  of  Friendly  Units* 

Prepare  Planning  Guidance 

Develop  Courses  of  Action 

Develop  Staff  Estimates 

Prepare  Concept  of  Operations 

Prepare  Outline  Plan 

Prepare  Scheme  of  Maneuver 

Prepare  Plan  of  Support  Fires 

Prepare  Landing  Plan 

Prepare  Plan  for  Employment  of  Aviation 

Prepare  Intelligence  Annex 

Prepare  Other  Annexes 

Analyze  Rehearsal  Results  While  Afloat 

Update,  Modify,  Produce,  Plans,  and  Orders  While  Afloat 

Request  Landing  of  On  Call/Non  Scheduled  Waves 

Ecnelon  Carmand  Agencies  Asnore 

Conduct  lirmediate  Ground  Planning 

Insert,  Delete,  Modify,  Control  Measures 

Prepare  Ground  Reports,  Requests,  and  Orders 

Modify  Fire/Air  Support  Schedule 

Modify  Target  List 

Adjust  Resources  to  Requirements** 

Generate  Flight  Schedule 

Prepare  Aviation  Reports,  Requests,  and  Orders 

Prepare  Flight  Plans 

Conduct  Immediate  Aviation  Planning 

Monitor  Status/Oirect  Employment  of  Collectors 

Correlate  Incoming  Information 

Perform  Combat  Information  Coordination 

Analyze  Incoming  Information 

Prepare  Reports /Studies 


*  Includes  assessment  of  combat  readiness. 

**  Was  added  as  a  subtask  of  allocate  aircraft  resources,  the 
other  subtasks  being  of  the  monitoring  type. 


PROBLEM 

SOLVING 

INFORMATION  & 
DISCRIMINATION 
MEASURES 

.67 

.60 

I. DO 

|  1.00 

1.00 

.90 

.35 

.40 

.50 

j  .so 
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TABLE  A-8 


IMPORTANT  DECISION  TASKS  MATCHING  WELL 
SELECTED  DECISION-AIDING  TECHNIQUES 


DECISION-AIDING  TECHNIQUE 

DECISION  TASKS 

.  Problem  Solving 

.  Conduct  Immediate  Aviation  Planning 

.  Allocate  Aircraft  Resources 

.  Information  and  Discrim¬ 
ination  Measures 

.  Perform  C.I.  Coordination 

.  Modify  Target  List 

.  Classification 

.  Correlate  Incoming  Information 

.  Conduct  Immediate  Ground  Planning 

.  Conduct  Immediate  Aviation  Planning 
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TASK: 


ESTABLISH  COLLECTION  REQUIREMENTS 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 

Group 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 

2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


i 

1 

i 

I 

J 

] 

1 

i 


TASK: 


MAINTAIN  CONTINGENCY  FILES 


NATURE:  1.1.  Searching  for  and  Receiving  Information 

2.1.  Information  Processing 


* 


TASK: 


DEVELOP  THE  COLLECTION  PLAN 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 


3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


I 


f 


< 


i 


TASK: 


REQUEST  COMBAT  READINESS  OF  FRIENDLY  UNITS* 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


1.1.  Searching  for  and  Receiving  Information 

Multi -Attribute 

Group 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  2 


3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


This  should  Include  assessment  of  combat  readiness  In  which  case  It 
becomes  a  decision  task  classified  as  above. 


TASK: 


PREPARE  PLANNING  GUIDANCE 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 
Individual 
Dynami  c 
Repetitive 
Risk 

Ambiguous 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  1 

2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 
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TASK: 

DEVELOP  COURSES  OF  ACTION 

NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi-Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 

Decision  Making 

Time  Relaxed 

Normal  Range 

Type  3 

FUNCTIONAL 

REQUIREMENTS: 


2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 


TASK: 


DEVELOP  STAFF  ESTIMATES 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  2 


4.  Alternative  Evaluation/Selection 


•  I 


TASK: 


BRIEF  COMMANDER 


NATURE: 


3.  Communi eating 


TASK: 

NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Including  CMDR's 
amplification  of 


PREPARE  CONCEPT  OF  OPERATIONS* 

Decision  Task 

Multi -Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  2 

4.  Alternative  Evaluation/Selection 


decision.  Actually  the  concept  of  ops  Is  only  an 
the  decision. 
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TASK: 


PREPARE  OUTLINE  PLAN 


NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi -Attribute 

Individual 

Static 

One  Shot 

Certainty 

Well  Defined 

Decision  Making 

Time  Relaxed 

Normal  Range 

Type  3 

FUNCTIONAL 

REQUIREMENTS: 

2.  Alternative  Development 

4.  Alternative  Evaluation/Selection 

I 


t 

I 


; 


TASK: 


PREPARE  SCHEME  OF  MANEUVER 


NATURE:  Decision  Task 

ATTRIBUTES:  Multi -Attribute 

Group 
Static 
One  Shot 
Certainty 
Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 

FUNCTIONAL 

REQUIREMENTS:  4.  Alternative  Evaluation/Selection 


t 

i 


TASK: 


PREPARE  PLAN  OF  SUPPORTING  FIRES 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 
Group 
Static 
One  Shot 
Certainty 
Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 


2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 
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TASK: 


PREPARE  THE  LANDING  PLAN 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 
Group 
Static 
One  Shot 
Certainty 
Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 
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TASK: 


PREPARE  THE  PLAN  FOR  EMPLOYMENT  OF  AVIATION 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 
Group 
Static 
One  Shot 
Certainty 
Well  Defined 
Decision  Making 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 


TASK: 


PREPARE  INTELLIGENCE  ANNEX 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


i 


TASK: 


PREPARE  OTHER  ANNEXES 


NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi -Attribute 

Individual 

Static 

One  Shot 

Risk 

Well  Defined 

Decision  Making 

Time  Relaxed 

Normal  Range 

Type  3 

FUNCTIONAL 

REQUIREMENTS: 

4.  Alternative  Evaluation/Selection 

( 


TASK: 


ANALYZE  REHEARSAL  RESULTS  WHILE  AFLOAT 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 
Group 
Static 
One  Shot 
Certainty 
Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  2 

1.  Problem  Recognition 
4.  Alternative  Evaluation/Selection 


3 
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TASK: 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


UPDATE,  MODIFY,  PRODUCE  PLANS  AND  ORDERS 
WHILE  AFLOAT 

Decision  Task 

Multi -Attribute 
Group 
Dynamic 
Repeti ti ve 
Risk 

Well  Defined 
Decision  Making 
Time  Relaxed 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 
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MONITOR  STATUS  OF  ASSAULT  ELEMENTS 

1.1.  Searching  for  and  Receiving  Information 

1.2.  Identifying  Objects  Actions  Events 


TASK: 


REQUEST  LANDING  OF  ON  CALL/NON  SCHEDULED 
WAVES 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 
Individual 
Dynamic 
Repeti ti ve 
Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  2 

4.  Alternative  Evaluation/Selection 


TASK: 


ECHELON  COMMAND  AGENCIES  ASHORE 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 

Group 

Dynamic 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  2 

4.  Alternative  Evaluation/Selection 
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RECEIVE,  RECORD,  DISPLAY,  INCOMING  INFORMATION 


TASK: 

NATURE:  1.1.  Searching  for  and  Receiving  Information 

3.  Comnunicati ng 

! 


f 


TASK: 


MONITOR  FRIENDLY  UNIT  MOVEMENT 


NATURE: 


1.1.  Searching  for  and  Receiving  Information 

1.2.  Identifying  Objects  Actions  Events 


TASK: 


CONDUCT  IMMEDIATE  GROUND  PLANNING 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 
Individual 
Dynamic 
Repeti ti ve 
Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  2 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selectiori 

5.  Feedback  Monitoring 


TASK: 


INSERT,  DELETE,  MODIFY,  CONTROL  MEASURES 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

1.  Problem  Recognition 

2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 
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TASK: 


PREPARE  GROUND  REPORTS,  REQUESTS  AND  ORDERS 


NATURE:  Decision  Task 

ATTRIBUTES:  Multi -Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

FUNCTIONAL 

REQUIREMENTS:  2.  Alternative  Development 

4.  Alternative  Evaluation/Selection 
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TASK: 


DISSEMINATE  GROUND  REPORTS,  REQUESTS  AND 
ORDERS 


NATURE: 


3.  Communicating 


rr 


ibis 


TASK: 

NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


MODIFY  FIRE/AIR  SUPPORT  SCHEDULE 

Decision  Task 

Multi -Attribute 
Group 
Dynamic 
Repeti ti ve 
Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 
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TASK: 


MODIFY  TARGET  LIST 


NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi-Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Well  Defined 

Decision  Making 

Time  Critical 

Normal  Range 

Type  2 

FUNCTIONAL 

REQUIREMENTS: 

4.  Alternative  Evaluation/Selection 

i 


TASK: 

NATURE: 

i 

i 

\ 

i 

! 

t  ; 

i  t  •  i 


MAINTAIN  AIR  DISPLAY  SITUATION  STATUS  BOARD 
3.  Communicating 


I 


TASK:  MONITOR  AIRCRAFT  TACTICAL  AIR  REQUESTS 

NATURE:  1.1.  Searching  for  and  Receiving  Information 

1.2.  Identifying  Objects  Actions  Events 


TASK: 


MONITOR  AIRCRAFT  AVAILABILITY 


NATURE: 


1.1.  Searching  for  and  Receiving  Information 

1.2.  Identifying  Objects  Actions  Events 


MONITOR  AIRCRAFT  LOCATION 

1.1.  Searching  for  and  Receiving  Informati 

1.2.  Identifying  Objects  Actions  Events 


TASK: 


ADJUSTS  RESOURCES  TO  REQUIREMENTS  (ALLOCATE 
AIRCRAFT  RESOURCES) 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


( 

I. 


Decision  Task 

Multi -Attribute 

Individual 

Dynamic 

Repetitive 

Risk 

Ambiguous 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 

4.  Alternative  Evaluation/Selection 

5.  Feedback  Monitoring 


TASK: 


GENERATE  FLIGHT  SCHEDULE 


NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi -Attribute 

Group 

Dynamic 

Repeti ti ve 

Risk 

Well  Defined 

Decision  Making 

Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selection 


FUNCTIONAL 

REQUIREMENTS: 


TASK: 


PREPARE  AVIATION  REPORTS,  REQUESTS  AND 
ORDERS 


NATURE: 

Decision  Task 

ATTRIBUTES: 

Multi -Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Well  Defined 

Decision  Making 

Time  Critical 

Normal  Range 

Type  3 

FUNCTIONAL 

REQUIREMENTS: 

2.  Alternative  Development 

4.  Alternative  Evaluation/Selection 
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PREPARE  AIRCREW  BRIEF 


3.  Comnuni eating 


TASK: 


PREPARE  FLIGHT  PLANS 


NATURE: 

ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Decision  Task 

Multi -Attribute 

Group 

Static 

One  Shot 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 
4.  Alternative  Evaluation/Selecti 


MONITOR  AIRCRAFT  TRACKS 


1.1.  Searching  for  and  Receiving  Information 

1.2.  Identifying  Objects  Actions  Events 


TASK: 


CONDUCT  IMMEDIATE  AVIATION  PLANNING 


NATURE:  Decision  Task 

ATTRIBUTES:  Multi -Attribute 

Individual 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  2 

FUNCTIONAL 

REQUIREMENTS:  3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 

5.  Feedback  Monitoring 


TASK: 


CONTINUITY  OF  OPS  DURING  DISPLACEMENT 


NATURE:  N/A 


[ 

? 


TASK: 

NATURE: 


CONTINUITY  OF  OPS  DURING  DEGRADED  MODE 
N/A 


1 


TASK: 


MONITOR  STATUS/DIRECT  EMPLOYMENT  OF  COLLECTORS 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 
Individual 
Dynamic 
Repeti ti ve 
Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


TASK: 


RECORD  REPORTS  FROM  COLLECTORS 


NATURE:  1.1.  Searching  for  and  Receiving  Information 

2.1.  Information  Processing 


\ 


TASK: 


CORRELATE  INCOMING  INFORMATION 


NATURE:  Decision  Task 

ATTRIBUTES:  Multi-Attribute 

Individual 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

FUNCTIONAL: 

REQUIREMENTS:  1.  Problem  Recognition 

3.  Information  Acquisition  and  Evaluati 
5.  Feedback  Monitoring 


TASK: 


CREATE/UPDATE,  DELETE  TRACKS 


NATURE: 


2.1.  Information  Processing 


TASK: 


PERFORM  COMBAT  INFORMATION  COORDINATION 


NATURE:  Decision  Task 

ATTRIBUTES:  Multi -Attribute 

Individual 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  2 

FUNCTIONAL 

REQUIREMENTS:  3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


TASK: 


ANALYZE  INCOMING  INFORMATION 


NATURE: 


Decision  Task 


ATTRIBUTES: 


FUNCTIONAL 

REQUIREMENTS: 


Multi -Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Ambiguous 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 


f  1 

I 


TASK: 


UPDATE  INTELLIGENCE  FILE 


NATURE: 


2.1.  Information  Process i 


i 


TASK: 


PREPARE  REPORTS/STUDIES  RESPONSES 


NATURE:  Decision  Task 

ATTRIBUTES:  Mul ti -Attribute 

Group 

Dynamic 

Repetitive 

Risk 

Well  Defined 
Decision  Making 
Time  Critical 
Normal  Range 
Type  3 

FUNCTIONAL 

REQUIREMENTS:  2.  Alternative  Development 

3.  Information  Acquisition  and  Evaluation 

4.  Alternative  Evaluation/Selection 
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TASK: 


AUTOMATICALLY  DISSEMINATE  COMBAT  INFORMATION 


NATURE  1.1  Searching  for  and  Receiving  Information 


! 

k 


I 


I 

I 


TASK: 


AUTOMATICALLY  DISSEMINATE  RESPONSES  TO 
QUERIES 


NATURE: 


1.1.  Searching  for  and  Receiving  Information 


f 


i  i 

i  l 

i  i 


i 


TASK: 


DISSEMINATE  REPORTS/STUDIES 


NATURE: 


1.1.  Searching  for  and  Receiving  Information 


! 


1 


I 


i 


f 

4 


I 


APPENDIX  C 

DEFINITION  OF  TCO  CAPABILITIES 


Test  02-79 

ICO  Capabilities  Identification 


CAP  f  Capability 

1.  ENTER  GRAPHICS  MANUALLY  ON  LINE 

The  capability  to  use  a  TCO  terminal  to  interact  directly  with 
the  TCO  Data  Base  to  create  graphic  displays. 

2.  EXCHANGE  TRACK  DATA  AUTOMATICALLY 

The  capability  to  display  graphically  or  textually,  position 

location  information  from  other  Marine  Corps  Tactical  Automated 
Command  and  Control  systems  (such  as  PLRS  and  TAOC-85) 
automatically,  i.e.,  without  human  intervention  between  the 
systems. 

3.  ENTER  TEXT  AUTOMATICALLY 

The  capability  to  view  information  that  is  not  already  in  the 
data  base  (e.g.,  an  incoming  message)  on  a  display  and,  when 
ready,  without  having  to  manually  retype  it,  to  enter  it  by  means 
of  a  simple  operator  action,  such  as  pressing  a  button. 

4.  ENTER  DATA  VIA  MACHINE  READABLE  teDIUM 

The  capability  to  enter  data  into  TCO  by  devices  such  as  magnetic 
tape,  OCR  equipment  and  so  on. 

5.  ENTER  TEXT  MANUALLY  ON  LINE 

The  capability  to  use  a  TCO  terminal  to  interact  directly  with 
the  TCO  Data  Base  to  create  textual  displays. 

6.  STORE  GRAPHICS  INFORMATION  IN  DATA  BASE 

The  capability  to  store  data  which  was  input  graphically. 

The  TCO  Data  Base  will  retain  the  data  for  subsequent  recall  and 
use.  The  graphics  data  can  be  in  the  form  of  control  measures, 
symbols  (newly  drawn  or  from  existing  library),  charts  or  graphs, 
terrain  features,  and  so  on. 

7.  PROCESS  TEXT  IN  PLANNING  FRAteWORK 

The  capability  to  enter,  delete,  and  store  textual  information  in 
the  TCO  Planning  Framework.  The  Planning  Framework  is  a 
structured  file  in  which  all  information,  irrespective  of  level 
of  command,  developed  during  planning  for  an  operation  is  stored 
in  doctrinal  formats  for  an  Op  Plan/ Annexes.  It  provides  users 
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C-l 


at  all  echelons  the  best  information,  available  within  the  MAGTF 
TCO  during  the  planning  phase.  It  provides  the  capability  to 
review,  correlate,  store  and  retrieve  planning  information,  so  as 
to  assist  concurrent  planning. 

5TQRE-.mT.IH.,  JOURNAL 

The  capability  of  the  system  to  store  textual  information  in  the 
unit  journal  format.  Both  automatic  and  manual  entry 
capabilities  are  available. 

STORE  MESSAGE  HEADER  INCOMING  MESSAGE  QUEUE 

A  capability  whereby  the  header  (title)  information  of  messages 
coming  into  a  TCO  terminal  are  filed  in  a  queue  until  such  time 
as  the  operator  is  able  to  review  them  and  take  a  subsequent 
action . 

SIQPS-TEXT..IH-PA.IA  BA3£ 

The  capability  of  TCO  to  be  able  to  store  textual  data  and 
information  in  the  data  base.  TCO  is  more  than  an  automated 
typewriter  or  printer.  Messages,  orders,  plans,  and  so  on  can  be 
retained  through  automation  for  future  recall  and  use.  Other 
capabilities  describe  some  designated  methods  of  'how'  the  text 
information  should  be  stored,  processed  and  manipulated,  (e.g., 
store  by  preformatted  display,  select  text  from  prompt  list,  word 
processing,  etc). 

PROCESS  TEXT/GRAPHICS  VIA  REMDTE  TERMINAL 

The  capability  to  interact  and  perform  textual  and  graphics 
operations  such  as  inputting,  manipulating,  sorting,  storing  and 
retrieving  data  while  at  locations  away  from  a  TCO  center,  by 
using  such  devices  as  the  hand-held  Digital  Communications 
Terminal  connected  to  a  field  radio. 

HOOK  TO  AMPLIFY  GRAPHIC  DISPLAY 

The  capability  of  an  operator  at  a  terminal  working  on  a  graphic 
display  to  use  a  device  such  as  a  light  pen  or  cursor  to  select  a 
particular  item  on  the  screen,  thereby  identifying  this  item  to 
the  system,  at  which  time  information  such  as  U1M  coordinate, 
unit  ID,  etc.,  is  displayed  in  the  textual  portion  of  the  display 
screen . 

INTER_.SYST£M  GRAPHIC  QUERIES 


The  capability  to  automatically  query  for  graphic  information 
from  other  systems.  For  example,  MIFASS  can  be  queried  for  the 
display  of  fire  control  measures  such  as  the  FCL,  FSCL,  eto. 


14.  REQUEST  GRAPHICS  BY  PLAIN  LANGUAGE  QUERY 

The  capability  to  enter  a  question  requesting  the  display  of 
graphics  information  using  Ehglish-like  language  instead  of  code. 

15.  REQUEST  GRAPHICS  BY  INTRASYSTEM  QUERY 

The  capability  to  retrieve  graphic  information  from  any  other  TCO 
centers  without  the  need  to  exchange  operator-to-operator 
messages. 

16.  REQUEST  GRAPHICS  BY  SRI 

The  capability  to  establish  a  request  for  graphic  information 
against  the  data  base.  The  information  requested  will  be 
automatically  provided  on  a  continuous  basis  as  new  information 
beccmes  available  or  data  is  updated. 

17.  SELECT  GRAPHICS  FROM  PROMPT  LIST 

The  capability  to  call  into  view  a  menu  of  all  available  graphic 
symbols  and  select  what  one  wants. 

18.  HOOK  TO  AMPLIFY  TEXT  DISPLAY 

The  capability  of  an  operator  working  on  a  display  terminal  to 
use  a  device  such  as  a  light  pen  or  cursor  to  select  a  particular 
word  or  phrase  on  the  screen  thereby  identifying  this  item  to  the 
system,  at  which  time  information  such  as  unit  strength,  supply 
status,  etc.,  is  displayed.  An  expansion  of  this  capability  is 
called  Close  Control  Text,  see  #45. 

19.  INTERSYSTEM  TEXT  QUERIES 

The  capability  to  automatically  query  for  textual  information 
from  other  systems.  For  example,  MAGIS  can  be  queried  for 
intelligence  summaries. 

20.  REQUEST  TEXT  BY  PLAIN  LANGUAGE  QUERY 

The  capability  to  enter  a  question  requesting  the  display  of 
textual  information  using  English-like  language  instead  of  code. 

21.  BIIBASXSTSM  TEXT  QUERIES 

The  capability  to  query  textual  information  resident  in  another 
TCO  center  without  requiring  an  exchange  of  messages  between 
operators . 
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22.  REQUEST  TEXT  BY  STANDING  REQUEST  FOR  INFORMATION 

The  capability  to  establish  a  request  for  text  information 
against  the  data  base.  The  information  requested  will  be 
automatically  provided  on  a  continuous  basis  as  new  information 
becomes  available  or  data  is  updated. 

23.  SELECT  TEXT  PROM  PROMPT  LIST 

The  capability  to  select  the  desired  textual  data  display  from  a 
menu/list  provided  as  a  display  on  the  screen. 

24.  SELECT  PREFORMATTED  DISPLAY 

The  capability  to  select  the  desired  format  required  from  a  list 
of  all  formats  resident  in  the  TCO  System. 

25.  PRINT  GRAPHICS  BY  OPERATOR  ACTION 

The  capability  to  have  a  hard  copy  print  made  of  a  graphic 
display  by  simple  means,  such  as  pressing  a  button. 

26.  PRINT  TEXT  AUTOMATICALLY  UPON  RECEIPT 

The  capability  to  designate  a  category  or  class  of  messages  that 
would  be  automatically  printed  in  hard  copy  upon  receipt  at  a 
center . 

27.  PRINT  TEXT  BY  OPERATOR  ACTION 

The  capability  to  have  a  hard  copy  print  made  of  a  text  display 
by  simple  means,  such  as  pressing  a  button. 

28.  DISPLAY  GRAPHICS  AUTOMATICALLY  UPON  RECEIPT 

The  capability  to  update  an  in-view  graphics  display  to 
immediately  display  new  information  received  at  the  center 
without  requiring  operator  action. 

29.  PROCESS  GRAPHICS  IN  SCRATCH  PAD 

The  capability  to  assemble,  compile,  interpret,  generate,  sort, 
manipulate,  etc.,  graphic  data  and  Information  at  a  terminal 
without  the  work  being  accessible  by  all  TCO  centers.  After 
using  his  "local"  scratch  pad  to  accomplish  his  work,  the 
operator  can  then  enter  the  data  into  the  main  data  base  where  it 
becomes  accessible  to  all. 
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30.  MAP  DISPLAY  CONTROL 

Tbe  capability  of  the  computer  to  orient  the  graphics  on  a 
display  screen  to  the  map  placed  behind  it. 

31.  HIGHLIGHT  GRAPHICS 

The  capability  to  enhance  specified  symbology  on  a  graphic 
display  using  techniques  such  as  increasing  light  intensity.  Tbe 
capability  may  be  programmed  or  operator  generated. 

32.  CRAPHIC-SELSSIIYB-BRASS 

The  capability  to  unclutter  a  graphic  display  on  a  terminal  by 
removing  from  sight  selected  symbols  or  lines  (also  referred  to 
as  "suppressing") .  This  capability  is  not  to  be  confused  with 
deleting  tbe  symbol  from  the  data  base. 

33.  SMDOTH  GRAPHIC  SYMBOLS 

The  capability  to  automatically  simplify  a  graphic  display 
whenever  tbe  symbology  being  requested  by  the  operator  can  be 
displayed  as  a  set  rather  than  in  terms  of  its  subsets.  Example, 
a  Company  CO  may  enter  his  platoon  positions.  Regiment  may  wish 
to  call  up  a  display  of  Company  positions.  The  system  will 
automatically  combine  the  platoon  positions  to  produce  a  single 
symbolic  depiction  of  the  company  position. 

34.  ANNOTATE  SOURCE  OF  SYMBOLS 

The  capability  to  automatically  display  alphanumeric 
identification  of  the  source  of  graphic  information.  For 
example,  when  Position  Location  information  is  entered  into  the 
system  either  manually  or  received  from  PLRS  it  is  automatically 
displayed,  and  the  source  of  the  information  is  distinguished  so 
the  operator  may  ascertain  its  reliability. 

35.  TItfi  TAG  INFORMATION 

The  capability  to  automatically  display  the  date/time/group 
representing  the  time  of  receipt  (TOR)  of  information.  For 
example,  the  display  of  enemy  location  information  utilizes 
standard  military  symbology.  When  an  enemy  unit  location  is 
displayed  the  symbol  will  be  time-tagged. 

36.  DISTINGUISH  FRIEND /ENEMY  UNIT 

The  capability  on  a  display  to  visually  differentiate  between 
symbols  representing  enmay  and  those  which  represent  friendly. 
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37. 


L 


The  capability  to  tell  the  difference  between  displayed  j 

Intelligence  data  which  has  been  processed  by  MAGIS  (Intel 
analysts)  and  combat  report  information  (raw)  not  yet  processed. 

! 

38.  CONTROL /DISPLAY  POINTER  4 

The  capability  to  move  a  "pointer"  on  a  display  screen  in  order 
to  interact  with  a  display. 

39.  CONSTRUCT  A  PROCESS  SYMBOLS 

The  capability  to  draw  or  create  symbols  on  a  display  screen  and 

then  have  them  entered  into  the  data  base,  as  opposed  to  being 

able  to  only  select  symbols  already  existing  in  a  library.  f 

40.  CLOSE  CONTROL  GRAPHICS 

The  capability  to  designate  by  cursor  or  "hook"  an  element  of  a  1 

graphics  display  and  then  perform  other  operations  on  the  system, 
all  of  which  will  be  in  relation  to  the  designated  element. 

41.  DISPLAY  TEXT  AUTOMATICALLY  UPON  RECEIPT 

The  capability  of  an  in-view  dedicated  textual  display  to  be 
automatically  updated  upon  receipt  of  new  information. 

42.  DISPLAY  TEXT  BY  OPERATOR  ACTION 

The  capability  to  display  on  a  terminal,  textual  information. 

43.  PROCESS  TEXT  IN  SCRATCH  PAD 

The  capability  to  assemble,  compile,  interpret,  generate,  sort,  j 

manipulate,  etc.,  text  data  and  information  at  a  terminal  without  * 

the  work  being  accessible  by  all  TCO  centers.  After  using  his 
"local"  scratch  pad  to  accomplish  his  work,  the  operator  can  then  | 

enter  the  data  into  the  main  data  base  where  it  becomes  1 

accessible  to  all. 

44.  SCROLL /PAGE  TEXT  | 

The  capability  to  read  text  information  on  the  terminal  screen  by  ; 

either  rolling  it  from  top  to  bottom  or  bottom  to  top,  or  by  | 

looking  at  a  section  at  a  time,  like  turning  pages,  depending 
upon  your  own  preference.  . 


[ 
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CLOSE  CONTROL  TEXT 


The  capability  to  designate  by  cursor  or  "book"  an  element  of  a 
text  display  and  then  perform  other  operations  on  the  system,  all 
of  which  will  be  in  relation  to  the  designated  element,  e.g., 
further  queries. 

INTRA  CENTER  DISSEMINATION  OF  TEXT /GRAPHICS 

The  capability  to  transfer  display  information  between  terminals 
in  the  same  center. 

PISfUAX  IN  CQNFSBfiHSE.  HOPE 

The  capability  of  users  at  different  centers  to  use  voice 
connunications  and  identical  TCO  displays  (usually  graphic)  for  a 
conference.  As  any  user  modifies  or  "points"  on  the  display,  the 
modification  or  "pointer"  is  displayed  at  all  the  terminals 
linked  in  the  conference  mode. 

INTRA  SYSTEM  DISSEMINATION  OF  TEXT /GRAPHICS 

The  capability  to  display  text  or  graphics  which  is  on  one 
terminal  in  one  center  on  any  terminal  located  in  another  center 
within  the  TCO  System.  Such  dissemination  may  be  specifically 
designated  by  the  operator,  as  in  the  case  of  a  distribution  list 
addressee,  or  as  a  general  update  of  the  data  base. 

INTER  SYSTEM  DISSEMINATION  OF  TEXT /GRAPHICS 

The  capability  to  exchange  data  with  other  systems  so  that 
information  identical  to  what  was  on  the  sender's  terminal  can  be 
displayed  on  the  recipient's  terminal. 

HIGH  PRECEDENCE  MESSAGE  ALERT 

The  capability  to  warn  the  operator  by  visible  (blinking  light, 
etc.)  or  audible  alert  that  a  message  exceeding  a  threshold  of 
precedence  he  has  set  has  arrived  and  has  not  yet  been  looked  at. 

CALL  BACK  UPON  RECEIPT  OF  REQUESTED  DATA  ALERT 

The  capability  to  alert  an  operator  when  the  answer  to  a  one-time 
request  (as  opposed  to  an  SRI  discussed  in  #16  and  #22)  has 
become  available  in  the  system. 

LOCAL  PARAtCTERS  ALERT 

The  capability  of  an  operator  to  set  thresholds  of  values  for 
certain  quantitative  data  which,  if  exceeded,  will  trigger 


alerts;  this  includes  tickler/alarm  clock  alerts,  as  well  as  unit 
status  information. 

53.  TASK  IDENTIFICATION /SCROLL  QUEUE 

The  capability  to  scroll  through  those  items  which  have  been 
stored  in  the  action  queue  (an  automated  "Pending"  basket)  and 
select  one  to  work  on. 

54.  RUM  COMBAT  SIMULATION 

The  capability  to  wargame  a  proposed  course  of  action  in  a  manner 
similar  to  what  is  done  on  the  TWSEAS  map  maneuver  controller. 

55.  RUN  SIMULATION  BY  SNAPSHOTS 

The  capability  to  select  any  moment  in  time  during  the  simulation 
discussed  in  #54  and  display  the  situation  at  that  mcment. 

56.  ENTER/DELETE  A/C  SORT  RATE  PARAteTER 

The  capability  to  set  the  appropriate  sortie  rate  value  for  the 
computer  to  use  in  performing  flight  scheduling  algorithms. 

57.  EMTSR /DELETE  MISSION  REQUIREMENTS  PARAMETER 

The  capability  to  specify  mission  requirements  such  as  Time  on 
Target,  Target  location,  etc.,  for  the  computer  to  use  in 
performing  flight  scheduling  algorithms. 

58.  ENTER /DELETE  A/C  LOCATIONS  PARAtCTER 

The  capability  to  enter  the  locations  (bases)  of  aircraft 
available  for  scheduling  for  the  computer  to  use  in  flight 
scheduling  algorithms. 

59.  ENTER/DELETE  A/C  CHARACTER  PARAtCTER 

The  capability  to  enter/ delete  the  characteristics  (range, 
ceiling,  speed,  payload,  etc.)  of  aircraft  available  for 
scheduling  for  the  computer  to  use  in  flight  scheduling 
algorithms . 

60.  EMTER/DELETB  UNIT  t<DVEM5NT  PARAECTER 

The  capability  to  enter  a  movement  rate  (e.g.,  2.5  mph,  subject 
to  terrain)  fbr  a  tnit  to  be  represented  in  the  oombat  simulation 
discussed  in  #54. 


The  capability  of  the  system  to  compute  relative  combat  power  of 
opposing  units  when  it  knows  the  weapons,  dispositions,  etc.,  of 
each  unit. 


The  capability  to  predict  the  time  needed  to  travel  a  given 
distance  over  given  terrain  oy  a  given  means. 


The  capability  to  predict  the  point  at  which  A/C  or  growd 
vehicles  will  require  fuel  or  how  much  fuel  will  be  required  by 
A/C  or  ground  vehicles  to  execute  a  given  mission. 


The  capability  to  produce  casualty  estimates  based  on  combat 
power  ratios  of  units  in  a  combat  simulation. 


The  capability  to  recoonend  allocation  of  A/C  to  missions  based 
on  parameters  entered  as  addressed  in  #56-#59i  #62  and  #63* 


The  capability  to  perform  weaponeering"  for  aviation  missions  by 
analyzing  target  characteristics  and  available  weapon 
characteristics  and  matching  the  two . 


The  capability  to  analyze  terrain  data  and  recommend  locations 
suitable  for  various  types  of  unattended  ground  sensors ;  the 
capability  to  display  the  coverage  which  would  be  provided  (e.g., 
circles/ fans)  by  a  proposed  placement  of  the  sensors. 


The  capability  to  calculate  the  number  and  type  of  mines  required 
to  lay  a  minefield  of  a  desired  density  over  a  giver,  area;  the 
capability  to  display  the  location  of  minefields  and  the  pattern 
of  mines  in  the  field  (safe  lanes,  etc.) 


The  capability  to  taka  input  from  real-time  trackers 
(specifically  PLRS,  radar  and  manually  entered  reports  of 
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position  location)  and  assign  appropriate  military  identifying 
symbology  to  the  tracks  while  displaying  them  at  the  correct 
location  on  a  screen  over  a  map  background. 

70.  AUTOMATIC  GENERATION  OF  TABLES 

The  capability  to  perform  computations  to  produce  a  table,  or 
update  tables,  as  specifically  illustrated  by  the  development  of 
the  Landing  Plan.  In  the  case  of  the  Landing  Plan,  once  the 
"Landing  serial  file"  format  is  filled  out  by  planners  at  each 
echelon,  TCO  produces  the  doctrinal  Landing  Plan  Tables  i.e., 
Serial  Assignment  Table,  Assault  Schedule,  etc.,  on  demand.  A 
similar  capability  is  used  in  the  development  of  the  Air  Combat 
Element  Flight  Schedule. 

71.  PERFORM  REASONABLENESS  CHECKS 

The  capability  to  check  human  inputs  against  allowable  values  in 
appropriate  cases  and  to  alert  the  operator  when  incorrect  values 
have  been  entered.  For  example,  in  preparing  a  landing  plan,  if 
more  personnel  are  assigned  to  an  LVTP7  than  it  can  carry  or  more 
helicopters  are  assigned  than  are  available,  the  system  will 
alert  the  operator. 

72.  OPERATE  IN  LOCAL  MODE 

The  capability  of  a  TCO  center  to  operate  independent  of  digital 
radio  corns  uni cations  with  the  rest  of  the  system,  as  in  the  case 
during  movement  to  the  objective  area  aboard  ship.  While  in 
local  mode,  each  center  is  capable  of  displaying  or  providing 
hardcopy  printouts  of  data  contained  within  its  own  computer's 
portion  of  the  data  base  and  accepting  updates  to  that  data,  via 
operator  inputs  either  manually  or  by  machine  readable  medium. 

73.  miSRFACB  PLRS 

The  capability  to  display  friendly  unit  location  information 
provided  by  the  Position  Location  Reporting  System  (PLRS)  by 
exchanging  data  with  PLRS  without  human  intervention. 

74.  INTERFACE  MTFASS 

The  capability  to  exchange  data  with  the  MIFASS  in  order  to 
display  fire  and  air  support  information  or  provide  maneuver 
information  to  fire  support  personnel. 

75.  INTERFACE  TAOC-85 

The  capability  to  exchange  data  with  the  Tactical  Air  Operations 
Central-85  such  as  aircraft  locations,  alerts,  etc. 
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76.  INTERFACE  MIPS 

The  capability  to  exchange  data  with  the  Marine  Corps  Integrated 
Personnel  System;  this  enables  the  TCO  user  to  display  personnel 
status,  wit  readiness  information,  and  so  on. 

77.  IHTSRP  ACS .  .fflLOOS 

The  capability  to  exchange  data  with  the  Marine  Corps  Integrated 
Logistics  Support  System.  This  enables  the  TCO  user  to  display 
logistic  status  and  readiness  information. 

78.  INTERFACE  MAGIS 

The  capability  to  exchange  intelligence  information  with  the 
Marine  Corps  Air -Ground  Intelligence  System.  Examples  of  such 
information  include:  spot  reports,  INTSUMS,  area  studies, 
intelligence  analysis  information,  EEI’s. 

79.  INTERFACE  EXTERNAL  SYSTEM 

The  capability  of  TCO  to  exchange  data  with  systems  external  to 
the  MAGTF  in  conformance  with  Joint  Interoperability  for  Tactical 
Command  and  Control  Systems  (JINTACCS)  standards.  Examples  of 
such  systems  would  be  Integrated  Tactical  Amphibious  Warfare  Data 
System  -  Navy  (ITAWES),  Navy  botical  Data  Systems  (NTDS), 
Tactical  Operations  System  -  O.S.  Amy  (TOS),  and  so  on. 

80.  OPERATE  WITH  PORTION  DATA  BASE 

The  capability  of  a  TCO  center  and  or  the  system  to  continue  to 
operate  although  a  portion  of  the  data  base  has  become 
inoperable,  or  unavailable  as  during  displacement . 

81.  OPERATE  WITH  PORTION  EQUIPMENT  SPITE 

The  capability  of  a  TCO  center  to  continue  to  operate  in  a 
degraded  mode  when  some  equipment  has  been  rendered  inoperable, 
or  when  some  equipment  is  unavailable  during  displacement. 

82.  LOAD /RELOAD  FROM  AUXILIARY  1BMBBX 

The  capability  of  a  TCO  center  to  divide  its  equipment  suite  into 
an  'A'  and  *B'  command  group  configuration.  Selected  programs 
would  be  stored  off-line  and  designated  critical  functions  would 
be  performed  on  both  groups  of  equipment  until  the  center  was 
re-established,  as  in  the  case  of  displacement  ashore. 
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The  capability  of  acne  of  a  TCO  center' a  f unotiona  to  be 
temporarily  assigned  to  another  oenter  during  degraded 
operations . 


I  Jil*W  4 '  C*m  *>K  W  *  W  Si 


The  capability  of  a  TCO  center  to  perform  funetione  temporarily 
on  behalf  of  another  degraded  center. 


The  capability  of  TCO  funotiona  to  be  performed  on  M1FASS 
equipment  during  degraded  mode  operations  or  displacement.  The 
Commander  may  designate  M1FASS  equipment  or  capabilities  to 
perform  functions  normally  assigned  to  TCO.  TCO  software  will  be 
operational  on  M2FASS  equipment. 


The  capability  of  the  operator  to  use  several  automated  features 
beyond  the  typical  automated  typewriter  to  aid  in  composition  and 
editing  of  documents,  examples  are: 

(1)  paragraph/sentence  manipulation,  additions,  and  deletions 

(2)  word/ number  searching 

(3)  auto  advance/backup 
auto/ capitalization,  etc., 


The  capability  to  create  a  large  visual  display  of  either 
graphics  and/or  text  suitable  for  viewing  by  a  group  of  people 
simultaneously. 


The  capability  to  draw  a  graphical  overlay  While  not  directly 
linked  up  to  the  computer  data  base,  i.e.,  not  at  an  interactive 
terminal.  Upon  completion  of  the  overlay  the  operator  can ,  by  a 
switch  action,  update  the  data  base. 


The  capability  of  the  operator  to  compose  a  graphic  or  textual 
display,  name  it,  store  it  and  retrieve  it  later. 
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The  capability  to  purge  text  and  graphio  data  from  the  data  base. 

91.  CALCULATE  LINE  OP  SIGHT 

The  capability  to  identify  any  two  points  on  a  graphio  display 
and  have  the  systea  tell  you  if  line  of  sight  exists  between 
then. 

92.  CALCULATE  MATERIEL  REQUIREtCHTS 

The  capability  to  allow  the  planner  to  compute  such  items  as 
ammuiltion  expenditure,  POL  consumption,  and  anticipated  materiel 
replacement  for  items  such  as  weapons,  vehicles,  and  equipment. 
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SURFACE  OF  THE  o-LEVEL  CONFIDENCE  ELLIPSE 
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In  this  appendix  a  formula  Is  derived  for  the  surface  of  the  a-level  confi¬ 
dence  ellipse  associated  with  a  two  dimensional  normal  distribution.  Consider 

f(x)  * — ■ — t  e”^  —  2  -  ( 2-dimens Ional  normal  distribution  p.d.f.) 

Let  E^  be  the  o- level  confidence  ellipse  which  is  such  that: 

a  «  Jj  f(x)dx 

ct 

E  Is  also  defined  by: 

01 

Ea  =  (xlx'z^x  <  C> 

where  C  Is  a  function  of  a  to  be  computed. 

Since  It  Is  assumed  that  z  Is  regular,  there  exists  a  diagonal  matrix 


and  an  orthogonal  matrix  P  such  that: 

I  «  POP"1 
and 

x  * 

Thus, 


dx  *  |P|d£  *  d^ 


where 


i  -7*  D  lJt 

*  f(x)dx  * - -  e  dy 

E  2ir|z|i  £' 

**  a  1  1  a 


2  2 

£•  .  (xlz'O'ViC)  ■  <*|^  +  ;■§<« 

d  b 


1  f*^  fb^  -  \£i*z.  . 

a  »  — i— r  e  2  1  dy.  e  c  c  dy? 

*■1*1*  0 

2  2 

Noting  that  |t|  ■  |D|  *  a  b  ,  and  performing  the  change  of  variables 
U1  *  yl/a  u2  *  y2/b  yields 


Thus, 


Cl  55  ir~  6 

L 


[erf(/£)r 


where  erf(u)  Is  defined  by: 

i  fu  -v2/2 

erf(u)  *  e  *  '*dx 

/2tt  q 


Consequently,  the  surface  S#  of  the  a-level  confidence  ellipse  Is  given  by: 

$o  *  irabC  *  wlerf1  (4»)]2|£| 

S  Is  consequently  proportional  to  the  determinant  of  z. 
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ANALYSIS  OF  ICC  SYSTEM  BEHAVIOR 
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This  appendix  proposes  a  model  for  the  analysis  of  the  ICC  system  behavior. 
The  model  selected  Is  graphically  portrayed  In  Figure  E-l.  It  Is,  of 
course,  a  queuing  model  since  the  overall  system  can  be  viewed  as  a  queue. 
It  Is  assumed  that  local  correlation  being  the  same  at  MAF,  division  and 
wing  level,  these  three  processes  can  be  viewed  similarly.  Local  corre¬ 
lation  is  viewed  as  a  birth-death  process:  sensor  reports  arrive  according 
to  a  Poisson  process  with  parameter  x  and  the  correlation  operator  acts 
as  an  exponential  server.  The  Interdeparture  time  Is  then  a  Poisson 
process  of  parameter  x  (Burke's  theorem).  It  is  logical  to  assume  that 
the  rates  of  arrival  of  sensor  messages  to  MAF,  wing  and  division  could 
be  different.  Thus,  the  various  arrival  rates  have  been  indexed  by  the 
level  which  serves  them,  l.e.,  x^,  Xq  and  x^. 

Proposed  modifications  thus  arrive  to  the  track  modification  queue 
according  to  a  Poisson  process  of  parameter  x  -  xM  +  xQ  +  xy.  Global 
correlation  can  be  modeled  as  a  birth-death  process  where  the  service 
time,  when  there  are  n  modifications  in  the  queue,  is  a  function  of  n. 

This  Is  due  to  the  fact  that  M^,  the  modification  in  front  of  the  track 
modifications  queue,  must  be  compared  to  all  the  modifications  which  are 
In  the  queue.  If  no  conflict  is  found  the  processing  time  Is  negligible 
and  we  do  not  expect  more  than  a  few  conflicts  (for  Instance,  3)  no 
matter  how  large  the  number  In  the  queue  Is.  Thus,  we  can  assume  that 
Un  *  constant  *  y  for  n  ^  3,  for  Instance. 

Using  the  state-transition-rate  diagram  depicted  In  Figure  E-2,  we  can 
Immediately  solve  {P^J,  the  distribution  of  the  number  In  the  system: 


IMPLEMENTATION 

DECISIONS 


FIGURE  E-l. 

QUEUING  MODEL  FOR  ICC  DECISION  SUPPORT  SYSTEM 


p  — 

0  Uj 


o  Vj  w 2 


k  «  1 


k  »  2 


k  >  3 


ll  VZ  w 


F(z)  *  I  Pk  zK  «  P 
k»o  * 


»  P  [l  +  ~  z  +  — - z2  (1  +  -  z  +  ...)1 

0  [  U1  VXUZ  U  J 

[l  +  —  z  +  — —  z2  - 1  —  1  (1) 

L  vl  vlv2  1-^-zJ 


if  ^  <  1  (ergodlcity  condition) 

Letting  z  =  1  in  (1)  will  yield  PQ  using  F(l)  *  1.  The  average  number 
in  the  system  will  be  computed  as  F  *  F'(l).  Thus,  F  can  easily  be 
obtained  as  a  function  of  the  system  parameters  x,  pj,  uz  a°d  v-  The 
average  time  in  the  system,  T,  will  then  be  computed  using  Little's  result 
F  a  XT.  Thus,  T  can  be  obtained  in  function  of  the  system  parameters, 
hence,  the  system  can  be  analyzed  with  a  few  realistic  assumptions.  It 
should,  however,  be  realized  that  only  simulations  could  actually  yield 
the  model ization  of  vy  Once  this  is  done,  the  expected  behavior  of  the 
system  can  easily  be  predicted. 
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This  appendix  describes  a  decision-aid  concept  for  situation  assessment 
using  Bayesian  classification  techniques.  The  application  of  the  matching 
principles  developed  during  the  first-year  program  to  the  MAB  decision 
task  situation  assessment  yielded  the  following  desirable  decision-aid 
features:  (1)  interactive,  (2)  real-time,  (3)  flexible,  and  (4)  alert 
capability.  Implementation  of  these  features  will  result  in  a  maximum 
suitability  score. 

The  decision  aid  concept  development  was  guided  by  an  analysis  of  the 
decision  task  situation  assessment  during  control  of  ground  operations. 
Marine  Corps  experts  with  experience  in  operations  and  intelligence  based 
at  Camp  Pendleton  were  consulted.  Doctrinal  publication  FMFM  2-1  (In¬ 
telligence)  was  also  used  as  a  basis  for  the  analysis. 

Figure  F-l  portrays  an  overview  of  the  decision  aid  concept.  In  this 
model  of  situation  assessment,  information  is  received  by  the  62  located 
in  the  intelligence  station  of  the  Intelligence  Center.  Upon  receipt  of 
this  information,  events  are  detected  and  taken  into  account  by  the 
decision  aid  which  Issues  the  latest  assessment  of  the  situation  and  an 
updating  of  the  priors.  The  G2/Decision  aid  interaction  takes  place 
within  the  doctrinal  framework  of  Essential  Elements  of  Information 
(EEI's)  which  correspond  to  possible  enemy  courses  of  action  and  Indica¬ 
tions  which  correspond  to  events.  Examples  of  EEI's  and  Indications 
are  presented  in  Table  F-l.  This  doctrinal  framework  was  also  used  by 
Spall  (1979)  for  the  purpose  of  situation  assessment;  his  method  of 
approach,  however,  was  different.  The  resulting  decision  aid  concept 
has  the  following  major  attributes: 

(1)  Is  adaptive. 

(2)  Provides  an  aiding  framework  to  both  62  and  commander. 


FIGURE  F-l. 

DECISION  AID  CONCEPT  OVERVIEW 


TABLE  F-l 


EXAMPLE  OF  AN  MAF  INTELLIGENCE  COLLECTION 
WORKSHEET  (ADAPTED  FROM  FMFM  2-1) 


EE  I 

INDICATIONS 

SPECIFIC  INFO  TO  BE  SOUGHT 

DETERMINE  IF  THE 

ENEMY  WILL  DEFEND 

LANDING  BEACHES 

AGAINST  ASSAULT. 

A.  LOCATION  A NO  STRENGTH  OF 
(1)  INFANTRY  UNITS 

<2)  artillery  UNITS 

(3)  TANK  UNITS 

(4)  ANTI-TANK  UNITS 

(1)  REPORT  LOCATION,  IDENTI¬ 
FICATION,  STRENGTH, 
ACTIVITIES  OF  ENEMY  IN 

VICINITY  OF  LANDING 

BEACHES. 

(2) 

• 

B.  EXTENSIVE  PREPARATION 

OF  FIELD  FORTIFICATIONS 

(6)  REPORT  PREPARATION  OF 

FIELD  FORTIFICATIONS  IN 

THE  VICINITY  OF  LAND  1 N6 

BEACHES 

• 

C.  DUMPING  AMMUNITION  ANO 

ENGINEER  SUPPLIES  AND 
EQUIPMENT 

(8)  REPORT  DUMPING  OF  AMMUNITION 
ANO  ENGINEER  SUPPLIES  AND 

EQUIPMENT  IN  THE  VICINITY  OF 

THE  LANDING  BEACHES 
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(3)  Establishes  a  communication  link  between  G2  and  commander 
facilitating  commander's  access  to  Information  In  real-time. 

(4)  Generates  timely  Information  by  enhancing  speed  of  informa¬ 
tion  aggregation  process. 

(5)  Provides  a  structured  data  base  to  Incorporate  Information 
relevant  to  mission  accomplishment. 

(6)  Exploits  human  ability  to  assess  conditional  probabilities 
accurately  and  provides  aiding  for  updating,  thus  overcoming 
conservatism. 

(7)  Provides  a  framework  for  Incorporation  of  other  aiding 
techniques  Into  the  system  (e.g.,  value  of  Information  for 
collection  plan). 

This  decision  aid  concept  will  be  refined  and  described  In  a  forthcoming 
paper. 
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